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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document describes the basic data transport functions of the Data Link Control (DEC) of High PErformance 
Radio Local Area Network Type 2 (HIPERLAN/2) systems. Separate ETSI documents provide details on the system 
overview, physical layer, radio link control sublayer, convergence sub-layers and conformance testing requirements for 
HIPERLAN/2. 

The present document is part 1 of a multi-part TS covering the HIPERLAN Type 2; Data Link Control (DEC) Layer, as 
identified below: 

Part 1: "Basic Data Transport Functions"; 

Part 2 : " Radio Link Control Sublayer" . 
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Scope 



The present document specifies the first phase of the basic data transport mechanism of the Data Link Control layer 
(DLC) of the HIPERLAN/2 system. It describes the technical characteristics of the following parts of the DLC layer: 
Error Control, Medium Access Control (MAC) and the mapping between the PHY and the MAC layers of 
HIPERLAN/2. HIPERLAN/2 is confined to the functions which are located in the two lowest layers of the open systems 
interconnection (OSI) model, the physical and the data link control layers. The HIPERLAN/2 also defines some 
functionalities related to the network layer in the OSI model. The HIPERLAN/2 system overview document, 
TR 101 683 [6], contains an overall description of the HIPERLAN/2 system. 

Extensions for different applications of the DLC are specified in other HIPERLAN/2 DLC extension technical 
specifications. The radio link control (RLC) sublayer contains functions for radio resource control, association control 
and connection control. It is specified in another HIPERLAN/2 technical specification. The interworking with higher 
layers is handled by convergence layers on top of the data link control layer. Packet and cell based convergence layers 
are defined in other HIPERLAN/2 technical specifications. The specification of a management information base will be 
described in a different HIPLERAN/2 specification. 

The present document does not address the requirements and technical characteristics for type approval and 
conformance testing. These are covered in separate Technical Specifications. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Feedback CHannel (ACH): transport channel where the results of access attempts made in the random access 
phase of the previous MAC frame is conveyed 

Access Point (AP): device that is responsible for the centralized control of the resources in a radio cell. It is usually 
connected to a fixed network 

Association Control Function (ACF): group of control functions that use the services of the RLC. These functions are 
responsible for the handling of the association between MT and AP 

Association control CHannel (ASCH): logical channel in the uplink that conveys new association and re-association 
request messages 

Broadcast CHannel (BCH): transport channel that broadcasts control information 

Broadcast Control CHannel (BCCH): logical channel that broadcasts control information which is relevant for the 
current MAC frame 

Central Controller (CC): provides control functionality equivalent to that of an access point but is not necessarily 
attached to a fixed network. This term is normally used if central controller and MT functionality are located in a single 
device. It mostly involves direct mode communication 

Centralized Mode (CM): in centralized mode, all data transmitted or received by a mobile terminal pass the access 
point or the centralized controller, even if the data exchange is between mobile terminals associated to the same access 
point or centralized controller 

DLC connection: HIPERLAN/2 DLC operates connection oriented. A DLC connection carries user or control data and 
is identified by a DLC connection identifier. A connection has a set of properties for the transfer of data agreed upon 
between the MT and the AP or between MT's and a CC 

DLC User Connection: DLC user connection is uniquely identified by the DLC connection ID and a MAC ID 

DLC User Connection Control (DUCC): group of control functions that uses the services of the RLC. It is responsible 
for the handling of DLC user connections 

Direct Mode (DM): data exchange between MTs associated with the same AP or CC takes place without passing but 
under control of the access point or the central controller 

direct link phase: part of a MAC frame that only contains the data exchanged directly between MTs using direct mode 
communication methods 

downlink phase: part of the Downlink transmission of a MAC Frame during which user and control data is transmitted 
from the access point or central controller to mobile terminals. The data transmitted can be user as well as control data 
in unicast, broadcast and multicast modes 

encryption function: function that is responsible for keeping user data and part of RLC signalling secret between 
HIPERLAN/2 devices 

Error Control (EC): error control is responsible for detection of transmission errors and, where appropriate, for the 
retransmissions. It is assumed that one error control instance is provided per DLC connection 

Frame CHannel (FCH): transport channel that is broadcast and which carries the frame control channel 

Frame Control CHannel (FCCH): logical channel that contains the information defining how the resources are 
allocated in the current MAC frame. Its content changes in general dynamically from frame to frame 
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logical channel: generic term for any distinct data path. A set of logical channel types is defined for different kinds of 
data transfer services. Each logical channel type is defined by the type of information it carries. Logical channels can be 
considered to operate between logical connection end points 

MAC frame: periodical structure in time that appears on the air interface and that determines the communication of 
HIPERLAN/2 devices 

Mobile Terminal (MT): device that communicates with an access point or with each other via a radio link. It is 
typically a user terminal 

PDU train: sequence of transport channels delivered to and received from the physical layer 

PHY mode: PHY mode corresponds to a signal constellation (Modulation alphabet) and a code rate combination 

radio cell: radio cell is the area covered by an access point or central controller. It is sometimes used as a term to 
describe an AP or CC and its associated terminals 

Radio Link Control (RLC) sublayer: control plane of the DLC which offers transport services for the radio resource 
control, association control function and the DLC user connection control 

Radio Resource Control (RRC): group of control functions that use the services of the RLC. It controls the handling 
of radio resources 

Random Access CHannel (RACH): logical channel in the uplink of the MAC frame in which the MTs can send 
signalling data for the DLC or the RLC. It is transported in the random channel 

Random access Feedback CHannel (RFCH): logical channel where the result of the access attempts to the random 
channel made in the previous MAC frame is conveyed 

Random CHannel (RCH): transport channel in the uplink of the MAC that carries the logical channels random access 
channel and association control channel. A contention scheme is applied to access it 

Random Access Phase: period of the MAC Frame where any MT can try to access the system. The access to this phase 
is based on a contention scheme 

Resource Grant (RG): allocation of transmission resources by an access point or a central controller 

Resource Request (RR): message from a terminal to an access point or central controller in which the current buffer 
status is conveyed to request for transmission opportunities in the uplink or direct link phase 

sector antenna: term is used to describe if an access point or central controller uses one or more antenna element 

transport channel: basic element to construct PDU trains. Transport channels describe the message format 

uplink phase: part of the MAC frame in which data is transmitted from mobile terminals to an access point or a central 
controller 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

a Number of retransmission access attempts made by an MT 

BoW Bottom of Window. Used when window handling is needed 

CW,. Contention window 

d 

k Window size 

L RSS level 

n Number of RCH slots in a frame where r,, is calculated 

d 

R Coding rate 

i,^ a uniformly distributed random integer between 1 and CW^^ 

RxBoW Receivers BoW 

TxBoW Transmitters BoW 

X^ The bitmap block number that contains the PDU of sequence number Xj, 

X|3j, The first sequence number in block X^ 



ETSI 



11 



ETSI TS 101 761-1 VI. 1.1 (2000-04) 



X. 



A PDU sequence number 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ABIR ARQ Bandwidth Increase Request 

ACF Association Control Function 

ACH Access feedback CHannel 

AP Access Point 

ARE ARQ feedback message request bit 

ARQ Automatic Repeat reQuest 

ASCH Association control CHannel 

BCCH Broadcast Control CHannel 

BCH Broadcast Channel 

BMB Bit Map Block 

BMN Bit Map block Number 

BPSK Binary Phase Shift Keying 

CAI Cumulative Acknowledgement Indicator 

CC Central Controller 

CL Convergence Layer 

CM Centralized Mode 

CRC Cyclic Redundancy Check 

C-SAP Control Service Access Point 

DCCH Dedicated Control CHannel 

DES Data Encryption Standard 

DFS Dynamic Frequency Selection 

DiL Direct Link 

DEC Data Eink Control 

DECC DEC Connection 

DUC DEC User Connection 

DUCC DEC User Connection Control 

DM Direct Mode 

EC Error Control 

FC Flow Control 

FCCH Frame Control CHannel 

FCH Frame CHannel 

H/2 HIPEREAN type 2 

IE Information Element 

IV Initialization Vector 

ECCH Eink Control CHannel 

ECH Eong transport CHannel 

EFSR Linear Feedback Shift Register 

ESB Least Significant Bit 

MAC Medium Access Control 

MAC ID MAC IDentifier 

MSB Most Significant Bit 

MT Mobile Terminal 

NET ID NET work IDentifier 

OFB Output FeedBack mode 

OFDM Orthogonal Frequency Division Multiplexing 

PDU Protocol Data Unit 

RACH Random Access CHannel 

RBCH REC Broadcast CHannel 

RCH Random CHannel 

RFCH Random access Feedback CHannel 

REC Radio Eink Control Protocol 

RG Resource Grant 

RR Resource Request 

RRC Radio Resource Control 
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RSS Received Signal Strength 

SAP Service Access Point 

SCH Short transport CHannel 

SDU Service Data Unit 

SSK Session Secret Key 

TDD Time Division Duplex 

TDMA Time Division Multiple Access 

U-SAP User Service Access Point 

UBCH User Broadcast CHannel 

UDCH User Data CHannel 

UMCH User Multicast CHannel 



Overview 



The present document describes the basic DLC functions for the purpose of transporting data and control information 
between HIPERLAN/2 devices. It consists of the functions and message formats for the AP and MT side. An overview 
of HIPERLAN/2 is given in TR 101 683 [6]. It is recommended that TR 101 683 [6] has been read before reading the 
present document. 



4.1 



Functional entities 



The HIPERLAN/2 basic protocol stack on the AP side and its functions are shown in figure 1 . It consists of the PHY 
layer on the bottom, the DLC layer in the middle and one or more convergence layers on top. The scope of the H/2 
standard ends at the upper end of the CL on top of which higher layers are located. 



Control Plane 



User Plane 



ne instance per MAC ID 



One instance per AP 



Higher Layers 
CL SAPs 



Convergence Layer 
DLC Control SAP DLC User SAP 



Radio Linl< Controlsublayer 



Data Link Control - 

Basic Data Transport Functioi 




Physical Layer 



One instance per DLC 
User Connection, 
identified by DUC ID 
(MAC ID + DLCC ID) 



Scope of 

HIPERLAN/2 

standards 



Figure 1 : BRAN H/2 protocol stack in the AP/CC 

The HIPERLAN/2 basic protocol stack on the MT side and its functions are depicted in figure 2. The difference to the 
model of the AP is that it contains only one RLC and MAC entity. The functionality of the MAC and RLC entity differs 
from that of the AP/CC whereas the error control functions are symmetrical, although this is not visible in the drawing. 
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Control Plane 



User Plane 



One instance per MAC ID 



One instance per MT 



Higher Layers 
CL SAPs 



Convergence Layer 
DLC Control SAP DLC User SAP 



Radio Linic Control sublayer 




Data Linic Control - 

Basic Data Transport Function 



Physical Layer 



One instance per DLC 
User Connection, 
identified by DUC ID 
(MAC ID + DLCC ID) 



Scope of 

HIPERLAN/2 

standards 



Figure 2: BRAN H/2 protocol stack in the lUIT 

The present document is confined to the definition of the highlighted part shaded in grey, the DLC basic data transport 
functions. It describes mainly the messages and their format and, where appropriate, the functions of the MAC and EC. 

NOTE: Architectures where the AP is split into an AP controller and one or more AP transceivers are not 

precluded by this specification. If the split between AP controller and AP transceiver is below the DLC 
layer, more than one MAC entity may exist in the AP controller. 

4.1.1 Error Control (EC) 

The EC is responsible for detection and recovery from transmission errors on the radio link. Moreover, it ensures 
in-sequence delivery of data packets. It is assumed that a dedicated EC instance is assigned to each DLC user 
connection. 

NOTE: No ARQ is applied to the RLC data and the error handling is performed by the RLC itself. 



4.1 .2 Medium Access Control (MAC) 



The Medium Access Control protocol is based on a dynamic TDMA/TDD scheme with centralized control. The MAC 
frame appears with a period of 2 ms. The allocation of resources is controlled by an AP or CC. It is assumed that one 
MAC entity with one instance is provided per AP or per MT. The MAC IDs are also used to administer broadcast and 
multicast services. The relation between MAC entities are created by a MAC ID which is unique in a radio cell, see 
subclause 5.5. L 

NOTE: The terms access point and central controller are partly used synonymously in the present document. 

In order to control the allocation of resources, the AP or CC needs to know the state of its own buffers and of the buffers 
in the MT. Therefore, the MTs report their buffer states in Resource Request (RR) messages to the AP or CC. Using this 
mechanism, the MTs request for resources in terms of transmission capacity. Moreover, an optional feature is to 
negotiate a fixed capacity allocation over multiple frames. The AP allocates the resources according to the buffer states 
on a fair basis and, if required, taking quality of service parameters into account. The allocation of resources are 
conveyed by Resource Grant (RG) messages. RRs and RGs are defined on a per-connection basis. 

Data and control information are mapped onto transport channels. The transport channels are the basic elements to 
construct PDU trains that are delivered to and received from the physical layer. Six types of PDU trains are allowed: 
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Broadcast, FCH-and-ACH, Downlink, Uplink with short preamble. Uplink with long preamble, and Direct link PDU 
train, see subclause 6.9.2. 



4.1 .3 Radio link Control (RLC) sublayer 



The Radio Link Control Sublayer (RLC) provides a transport service to the DLC User Connection Control, the Radio 
Resource Control and the Association Control Function. The Radio link Control sublayer is described in 
TS 101 761-2 [5]. 



4.1.4 Physical layer (PHY) 



The physical (PHY) layer of HIPERLAN/2 is specified in TS 101 475 [4]. It is based on the modulation scheme 
Orthogonal Frequency Division Multiplexing (OFDM). In order to improve the radio link capability due to different 
interference situations and distances of MTs to the AP or CC, a multi-rate PHY layer is applied, where the appropriate 
mode can be selected by a link adaptation scheme. The data rate which ranges from 6 to 54 Mbit/s can be varied by 
using different signal alphabets for modulating the OFDM sub-carriers and by applying different puncturing patterns to a 
mother convolutional code. BPSK, QPSK, 16QAM are used as mandatory modulation formats, whereas 64QAM is 
applied as an optional one. The mode dependent parameters are listed in table 1. 

Table 1 : Mode dependent parameters 



Modulation 


Coding rate 
R 


Nominal bit rate 
[Mbit/s] 


Data bits per 
OFDM symbol 


BPSK 


1/2 


6 


24 


BPSK 


3/4 


9 


36 


QPSK 


1/2 


12 


48 


QPSK 


3/4 


18 


72 


16QAM 


9/16 


27 


108 


16QAM 


3/4 


36 


144 


64QAM 


3/4 


54 


216 



4.1 .5 Other functions (informative) 

The present document is mostly restricted to the definition of messages that are exchanged between HIPERLAN/2 
devices. It does not, however, describe where the data in devices are stored and which entity is responsible for their 
generation. Therefore, the functional model may seem to be not complete and the allocation of a logical channel to a 
logical entity is not always possible with the simple model given above. 

For information, this section lists some functions that are or may be assumed to be present in a device but which will not 
be described in this specification. The list is and can not be complete. 

Among these entities are the following functions: 

MAC scheduler. This function is responsible for the allocation of resources for the transmission of user and 
control data in the uplink, downlink and direct link phases as well as the allocation of the appropriate number of 
RCH per MAC frame; 

a function that performs radio resource management, e.g. link adaptation, power control, admission control, 
congestion control, dynamic frequency selection, handover initiation, etc. 

NOTE: This specification describes the behaviour of some of the mentioned functions that may be normative. 

4.2 Service Access Points to the CL (Informative) 

The DLC exchanges service primitives with the Convergence Layer at the DLC-U-SAP and DLC-C-SAP. The 
primitives exchanged at the DLC-C-SAP between the convergence layer and the RLC are specified in TS 101 761-2 [5]. 
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NOTE: The primitives are defined only for the purpose of describing layer-to-layer interactions. These primitives 
are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. The following primitive definitions are informative. 

4.2.1 Primitive types 

Interface between layers 

Four primitive types may be used: 

- req (request) 

for a higher layer to request service from a lower layer; 

cnf (confirm) 

for the layer providing the service to confirm the activity has been completed; 

ind (indication) 

for a layer providing service to notify the next higher layer of any specific service related activity; 

- rsp (response) 

for a layer to acknowledge receipt of an indication primitive from the next lower layer. 

4.2.2 Parameter definitions 

Endpoint identifiers: some primitives contain an endpoint identifier. This identifier shall be used to distinguish 
primitives related to different protocol instances. As identifier the DLC User Connection ID shall be used. The use of 
this identifier is a local matter not defined in the present document. The identifier is defined as: 

- DLC User Connection ID (DUC_ID) 

Message unit: each piece of higher layer information that is included in the primitive is called a message unit. A series 
of one or more message units may be associated with each primitive where each separate unit is related to one 
information element in the corresponding CL layer message. The list of message units is derived from the message 
definitions by reference to the information elements that may contain information from or to the DLC. 

4.2.3 DLC-U-SAP 

The DLC-U-SAP describes the interface to the CL that offers a data transfer service for in-sequence delivery of 
DLC-SDUs. 

The following primitives are used: 

- DLC_UNITDATA {req, ind} 

Table 2: Primitives at the DLC user SAP 



PARAMETER 


REQ 


IND 


DLC User Connection ID 


Present 


Present 


Message units (possible elements) 
Interface Data 


Present 


Present 



Interface Data (ID) 

This parameter specifies the Interface Data unit exchanged between the CL and the DLC entity. The Interface Data 
represents a complete DLC-SDU. The DLC SDU has a size of 396 bits and is carried in the payload field of the UBCH, 
UMCH and UDCH, see subclause 6.2. 
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Logical and Transport channels 



Logical and transport channels are introduced in order to improve readability and to define exact terms for the structures 
that are used to construct MAC frames. In that sense, they are informative. However, the definitions of message contents 
and their meaning, numbers of bits and rules to construct them are normative. 

The names of the logical channels will mostly be used when message contents and their meaning are addressed and the 
names of the transport channels should reflect message lengths, rules to assemble a MAC frame and access methods, e.g. 
to the RCH. 

This section describes basic properties of the logical and transport channels and their addressing. Their contents and 
formats are given in clause 6. Logical channels are referred to with four letters abbreviation, e.g. DCCH. Transport 
channels are referred to with three letters abbreviation, e.g. BCH. 

5.1 Logical Channels and their characteristics 

5.1.1 Logical Channels 

A logical channel is a generic term for any distinct data path. A set of logical channel types is defined for different kinds 
of data transfer services as offered by the MAC entity. Each logical channel type is defined by the type of information it 
carries and the interpretation of the values in the corresponding messages. Logical channels can be considered to operate 
between logical connection end points and, hence, between logical entities. 

5.1 .2 Broadcast Control Channel (BCCH) 

The Broadcast Control Channel is used in downlink direction and conveys broadcast control channel information 
concerning the whole radio cell. It contains a fixed amount of data. 

The support of the BCCH is mandatory for APs and CCs. MTs shall be able to interpret the BCCH. 

5.1 .3 Frame Control Channel (FCCH) 

The FCCH is sent in downlink direction and conveys information that describes the structure of the MAC frame visible 
at the air interface. This structure is announced by resource grants (RGs). 

In the case of the RBCH, the DCCH and other DUCs, an RG corresponds to a number of LCHs and SCHs, the PHY 
modes to be used, and the location in the frame where the reception/transmission will take place. 

The following information can be transmitted in the FCCH: 

- an RG for SCHs and LCHs that can be used to transport information for: RBCH, DCCH, LCCH, UDCH, UBCH 
and UMCH; 

announcements of empty parts of the MAC frame. 

The length of the FCCH is variable and depends on the amount of IBs sent per MAC frame per sector. The support of 
the FCCH is mandatory for APs and CCs. MTs shall be able to interpret the FCCH. 

5.1 .4 Random access Feedback Channel (RFCH) 

The purpose of the random access feedback channel is to inform the terminals that have used the RCH in the previous 
MAC frame about the result of their access attempts. It is transmitted once per MAC frame per sector. 

The support of the RFCH is mandatory for APs and CCs. MTs shall be able to interpret the RFCH. 
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5.1 .5 RLC Broadcast CHannel (RBCH) 



The RBCH is used in downlink phase in CM and may be used by an MT in direct link phase in DM. It conveys 
broadcast control information concerning the whole radio cell. The information is only transmitted when necessary, 
which is determined by the AP/CC in CM, and determined by the originating MT in DM. Following information may be 
sent in the downlink RBCH: 

- Broadcast RLC messages (see TS 101 761-2 [5]); 

transmission of the assigned MAC ID to a non-associated mobile terminal (see TS 101 761-2 [5]); 

convergence Layer ID information; 

encryption seed. 

NOTE: The encryption seed is defined in subclause 6.7. 

The support of the downlink RBCH in APs/CCs and MTs is mandatory. The downlink RBCH shall be transmitted only 
when required but not more than once per MAC frame per sector antenna. 

The DiL RBCH shall be supported if the DM is supported. The DiL RBCH is used to convey broadcast control 
information in DM from any one MT to all other MTs in DM. 

5.1 .6 Dedicated Control CHannel (DCCH) 

The DCCH is used to carry RLC messages over the air interface, see TS 101 761-2 [5]. It can be used in the uplink, 
downlink and direct link phase. RLC messages between two terminals in DM are transmitted over the DCCH in the DiL 
phase, which is uniquely identified by the transmit and receive MAC IDs. The DCCH may also be used for the 
transmission of RRs in uplink direction according to the rules in subclause 6.3. 

NOTE: All RLC messages have a unique length that is selected such that the messages can be sent either in an 
SCH/RCH or in an LCH, see TS 101 761-2 [5]. It is assumed that the MAC decides whether an RLC 
message is mapped to an SCH or RCH. The method of this mapping process is out of the scope of the 
present document. 

The DCCH is established implicitly during association of a terminal without any explicit signalling. A DLCC ID and 
corresponding connection parameters are predefined, i.e. no connection setup is needed. Each associated terminal can 
use the DCCH for downlink and uplink and, if implemented, for the direct link phase. The unacknowledged error control 
mode is used for the DCCH, see subclause 6.4. 

DCCHs are transmitted in PDU trains (see subclause 6.9.2) together with UDCH and LCCH if those exist in the current 
frame. 

The support of the DCCH in both MT and AP/CC is mandatory for the uplink and downlink. It shall be supported for 
the direct link if the DM features are supported. 

5. 1 .7 User Broadcast CHannel (UBCH) 

The UBCH is used to transmit user broadcast data from the convergence layer. If the AP supports multiple convergence 
layers, multiple UBCHs may exist. The UBCH can be sent either in the downlink (by an AP or CC) or direct link (by an 
MT). 

UBCHs are transmitted in PDU trains (see subclause 6.9.2) together with or without LCCHs. 

The support of the UBCH in APs/CCs and MTs is mandatory. It shall be supported for the direct link if the DM features 
are supported. 

The UBCH shall either be transmitted in repetition or unacknowledged mode, see subclause 6.4. 
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5.1 .8 User Multicast CHannel (UMCH) 

The UMCH is used to transmit user multicast data. The UMCH can be sent either in the downhnk (by an AP or CC) or 
direct link (by an MT). 

UMCHs are transmitted in PDU trains (see subclause 6.9.2). 

The UMCH shall be transmitted in unacknowledged mode, see subclause 6.4. The support of the UMCH in the AP and 
CC, respectively, is mandatory. MTs shall be able to interpret the UMCH if they join a multicast group. It shall be 
supported for the direct link if the DM features are supported. 

5.1 .9 User Data CHannel (UDCH) 

The UDCH is used to transmit user data between the AP and an MT in CM, or between two terminals in DM. A UDCH 
is always granted together with zero or more SCHs for a DUC that is announced in an RG in the FCCH. 

UDCHs are transmitted in PDU trains (see subclause 6.9.2) together with or without LCCHs. 

The support of UDCH for uplink and downlink is mandatory for both MTs and APs/CCs. The support of the UDCH for 
the direct link is mandatory if the DM features are supported. 

5.1.10 Link Control CHannel (LCCH) 

The LCCH is in general bi-directional and is used to transmit ARQ feedback and discard messages between the EC 
functions in the AP and an MT for a certain UDCH in centralized mode. In direct mode, it is bi-directional and conveys 
ARQ feedback and discard messages between the EC functions in two MTs for a certain DLCC in the DiL phase. The 
LCCH is also used in uplink direction for the transmission of RRs for the uplink. RRs for the direct link shall not be 
transmitted in DiL LCCHs. The method to transmit RRs for the direct link is described in subclause 6.2.9.1.2. 

The LCCH is also used to transmit discard messages between the EC functions in the AP/CC and the MTs for a UBCH 
using repetition mode for both centralized mode and direct mode. 

LCCHs are transmitted in PDU trains (see subclause 6.9.2) together with or without UDCHs/UBCHs. 

The support of the LCCH for uplink and downlink is mandatory for both MTs and APs/CCs. The support of the LCCH 
for the direct link is mandatory if the DM features are supported. 

5.1 .1 1 Association Control CHannel (ASCH) 

The ASCH is only used in the uplink and conveys new association request and handover request messages on behalf of 
the RLC, see TS 101 761-2 [5]. These messages shall only be sent by terminals that are not associated to an AP or CC. 

The support of the ASCH is mandatory for APs/CCs and MTs. 

5.2 Transport channels and their characteristics 



5.2.1 Transport Channels 



The logical channels are mapped onto different transport channels that are referred to with three letter abbreviations, e.g 
LCH. The transport channels are the basic elements to construct PDU trains. Transport channels describe the basic 
message format. In the case of the RCH, the random access method and the collision resolution scheme is also a 
property of the transport channel. The message contents and their interpretation, however, are subject to the logical 
channels. Transport channels can carry a fixed amount of data, except the FCH that can carry a variable amount. 

The transport channel's names will be used in the present document for the purpose of an abstract definition of a 
message as well as the actual occurrence of the respective message. The rules for the handling of transport channels are 
given in clause 6. 
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All transmissions of messages shall start with the most significant bit of the first octet, followed by the remaining bits of 
this octet, then the most significant bit of the second octet, etc. An example for this rule is given in figure 3. If not 
defined otherwise, the bits in a field are a binary representation of a number. 





8 1 7 


6 5 


4 1 3 1 2 1 1 1 


Octet 1 


Res 


MSB Sequence Number 


Octet 2 


Sequence Number 


Payload 


Octet 3 
Octet 4 

Octet 51 


Payload 


Octet 52 


MSB CRC 


Octet 53 


CRC 


Octet 54 


CRC 



Figure 3: Example for the transmission order of DLC messages 

An overview of the characteristics of the transport channels is given in table 3. 

Table 3: Characteristics of Transport channels 



Transport channel 


Direction 


PHY mode 


Length [octets] 


Comments 


BCH 


Downlink 


Binary PSK and 
code rate Vi. 


15 


Sent in every MAC frame for each 
sector. 


FCH 


Downlink 


Binary PSK and 
code rate Vi. 


IVIultiple of 27 


Sent in every IVIAC frame for each 
sector that contains scheduled 
data. 


SCH 


DL/UL/DIL 


Set in FCCH 


9 


PHY mode is set and adapted per 
connection. 


LCH 


DL/UL/DIL 


Set in FCCH 


54 


PHY mode is set and adapted per 
connection. 


ACH 


Downlink 


Binary PSK and 
code rate y2. 


9 


Sent in every MAC frame for each 
sector. 


RCH 


Uplink 


Binary PSK and 
code rate Vi. 


9 


Contention based access. 



5.2.2 Broadcast CHannel (BCH) 

The BCH carries the BCCH. It shall be broadcast in downlink direction. One BCH shall be sent per MAC frame per 
sector antenna. The support of the BCH is mandatory for APs/CCs and MTs. 

5.2.3 Frame CHannel (FCH) 

The FCH carries the FCCH. It shall be broadcast in downlink direction. The support of the FCH is mandatory for 
APs/CCs and MTs. 
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5.2.4 Access Feedback CHannel (ACH) 



The ACH shall be used for sending RFCH in the downlink. The support of the ACH is mandatory for APs/CCs and 

MTs. 



5.2.5 Long transport CHannel (LCH) 



The LCH transports user data for the connections related to the granted UDCHs, UBCHs and UMCHs, as well as 
control information for the connections related to the DCCH and RBCH. Rules for the use of LCHs are given in 
clause 6. 

The support of the LCH is mandatory for APs/CCs and MTs. 



5.2.6 Short transport CHannel (SCH) 



The SCH transports short control information for the DCCH, LCCH and RBCH. Rules for the use of SCHs are given in 
clause 6. 

The support of the SCH is mandatory for APs/CCs and MTs. 

5.2.7 Random CHannel (RCH) 

The RCH is defined for the purpose of giving an MT the opportunity to send control information to the AP or CC when 
it has no granted SCH available. It can carry RRs, ASCH and DCCH data. The support of the RCH is mandatory for 
APs/CCs and MTs. 

The access scheme is a distributed random access method described in clause 6. 

5.3 Mapping between Logical and Transport Channels 

The mapping between logical channels and transport channels is depicted below for the uplink, downlink, and direct 
Hnk. 



BCCH FCCH RFCH LCCH RBCH DCCH UDCH UBCH UMCH 




BC H FCH 



ACH 



SCH 



LCH 



Figure 4: Mapping between logical channels and transport channels for the downlink 



UDCH 



DCCH 



LCCH 



ASCH 




LCH 



SCH 



RCH 



Figure 5: Mapping between logical channels and transport channels for the uplink 
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UDCH 



UBCH UMCH 



DCCH 



RBCH 



LCCH 




LCH 



SCH 



Figure 6: Mapping between logical channels and transport channels for the direct link 

The BCCH, FCCH and RFCH are directly mapped to the corresponding transport channels BCH, FCH and ACH. The 
LCCH carries control information (i.e. RRs, discard and ARQ feedback messages). These are mapped to the SCH. For 
the uplink it is also possible to use the RCH for RR messages. In the case of the DiL, the LCCH carries only ARQ 
feedback and discard messages between two terminals. These are mapped to the SCH only. 

The DCCH conveys information between two RLC entities and can be mapped to the LCH or SCH in the downlink and 
the LCH, SCH or RCH in the uplink. The DCCH in the DiL phase conveys information between two RLC entities and 
can be mapped to the LCH or SCH. The RBCH is mapped to the SCH or LCH. The UDCH transfers user data and is 
mapped to the LCH. The UBCH and UMCH for broadcast and multicast are mapped to the LCH. The ASCH is mapped 
to the RCH. 



5.4 



Overview of the MAC Frame 



The basic MAC frame structure for a single sector system is shown in figure 7. Each MAC frame shall consist of the 
transport channels BCH, FCH, ACH and at least one RCH. If user data is to be transmitted, a DL phase and/or an UL 
phase shall be provided. If direct mode is used and data has to be transmitted, it shall also contain a DiL phase between 
the DL and UL phase. The duration of the BCH is fixed. The duration of the FCH, DL phase, DiL phase, UL phase and 
the number of RCHs are dynamically adapted by the AP/CC depending on the current traffic situation. The order of the 
subcomponents shall be: BCH - FCH - ACH - DL phase - UL phase - RCHs for centralized mode, or 
BCH - FCH - ACH - DL phase - DiL phase - UL phase - RCHs for direct mode from the point of view of an MT. 

NOTE: The specified order is from an MT's point of view. This means that an AP may e.g. have several DL & UL 
phases and mix the phases randomly, as long as the order is kept for each individual MT. 



MAC-Frame 


MAC-Frame 


MAC-Frame 


MAC-Frame 






BCH 


FCH 


ACH 


DL phase 


UL phase 


RCHs 










...,-■■■■■■■" 


■■■■■-... 







DiL phase 



Figure 7: Basic IVIAC frame structure (Direct link phase optional) for a single sector system 

An example of the basic MAC frame structure from the AP's point of view in the case where multiple sectors are used is 
shown in figure 8. Each MAC frame shall consist of a sequence of BCHs. The number of BCHs is equal to the number 
of sectors the AP is using. After the sequence of BCHs that have a fixed duration, a sequence of FCH-and-ACH PDU 
trains (see subclause 6.9.2) follows for each sector. The FCH shall not be transmitted if no traffic is scheduled for that 
sector in the current frame. A sequence of RCHs is located after the uplink phase. At least one RCH per sector shall be 
present. The frame also contains at least one DL phase and/or UL phase for a particular sector if the corresponding FCH 
is present. 
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If direct mode is used and data is to be transmitted, the frame also contains a DiL phase. The DiL phase is located 
between the DL and UL phase. The duration of the FCH, DL phase, DiL phase, UL phase and the number of RCHs are 
dynamically adapted by the AP depending on the current traffic situation. 

Detailed rules for the composition of MAC frames are given in subclause 6.3.2. 
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Figure 8: Basic lUIAC frame structure for multiple sectors (N = number of sector used by the AP) 

5.5 DLC addressing 

5.5.1 MAC ID 

Each MT is assigned a MAC ID that is unique for the AP by the AP RLC entity during association. The MAC ID is 
coded with 8 bits. The association procedure is described in TS 101 761-2 [5]. 

If the AP or CC acts also as a terminal, it shall be assigned a unique MAC ID. 

NOTE: This MAC ID assignment is done internally by the AP or CC. 

MAC IDs and 224 - 255 are reserved for special purposes, see subclause 5.5.6. 

5.5.2 DLC Connection ID 

A DLC Connection ID (DLCC ID) is assigned to a connection by the AP RLC entity during connection setup. The 
DLCC ID is coded with 6 bits. The connection setup procedure is described in TS 101 761-2 [5]. 

In CM, the MT and the access point or central controller shall use the MAC ID and the DLCC ID to identify for which 
connection an MT is requesting and the AP/CC is granting resources. The combined MAC ID and DLCC ID is referred 
to as DLC User Connection ID (DUC ID) and shall be unique in a radio cell. The DLCC ID is used as a reference to a 
connection during its lifetime. 

In DM, the DLCC ID is used in combination with two MAC IDs, the source and destination MAC IDs. The combination 
of source MAC ID, destination MAC ID, and the DLCC ID uniquely defines a DUC ID for DM. 

5.5.3 NET ID 

The NET ID in the BCCH shall be the same for all access points that belong to the same network of a certain 
operator/owner for a given geographic area. APs or CCs with the same NET ID shall support the same set of 
convergence layers. 

The NET ID is split into two ranges: 

0-959: for common use. Before selecting a NET ID in this range, it should be assured that the chosen NET ID is 
unique in the coverage area of a network. 

960-1023: reserved for public systems. The assignment of a NET ID within this range is beyond the scope of the 
present document. 
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5.5.4 Access point ID 



Each AP/CC shall be assigned an access point ID (AP ID) with a length of 10 bits. This ID should be unique for a 
network in a certain geographic area. 

If an AP is decomposed into several transceivers, then each transceiver shall be allocated an AP ID. 

5.5.5 Sector ID 

Each sector in the AP/CC is assigned a sector ID with a length of three bits. If the sector ID is equal to zero, a single 
sector is used and the respective rules apply. If more than one sector is used, these shall be allocated a sector ID from 
to 7 in the order in which the BCH is transmitted. 

5.5.6 Logical channels addressing 

5.5.6.1 BCCH 

The BCCH is transmitted in the BCH and is identified by the occurrence of the BCH. 

5.5.6.2 FCCH 

The FCCH is transmitted in the FCH and is identified by the occurrence of the FCH. 

5.5.6.3 RFCH 

The RFCH is transmitted in the ACH and is identified by the occurrence of the ACH. 

5.5.6.4 RBCH 

The RBCH is announced in the FCCH and is identified by MAC ID = and DLCC ID = in the case of the downhnk. 
In the direct link, it is identified by the source MAC ID of the transmitting MT, MAC ID = and DLCC ID = 0. 

5.5.6.5 DCCH 

The DCCH is identified by DLCC ID = for each MAC ID in the centralized mode. For the direct mode, the DCCH is 
identified by the source and destination MAC IDs of the concerned MTs and DLCC ID = 0. The DCCH is announced in 
the FCCH. 

5.5.6.6 UBCH 

The UBCH for a particular convergence layer is identified by the unique MAC ID that shall be assigned dynamically by 
the RLC (see TS 101 761-2 [5]) in the AP/CC from the address range MAC ID = [1 - 223] and DLCC ID = 63. 

In direct mode, this unique MAC ID is used as the destination MAC ID of a direct link UBCH. The source MAC ID 
shall identify the originator of the direct link UBCH. 

5.5.6.7 UMCH 

MAC IDs = [224 - 255] shall be reserved for multicast connections. The assignment is performed by the AP/CC and 
details can be found in TS 101 761-2 [5]. For multicast traffic using multicast MAC IDs = [224 - 254], DLCC ID = 63 
shall be used. The use of other DLCC IDs for multicast connections with MAC IDs = [224 - 254] is not considered in 
the present document. The MAC ID identifies the UMCH for the MT. 

NOTE: The use of other DLCC IDs may be specified in a future extension of the present document. 

In order to handle situations where more multicast connections are required, it shall be allowed to multiplex traffic from 
several multicast groups over MAC ID = 255. The support of multicast addresses is mandatory for MTs and APs/CCs. 
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In direct mode, the MAC ID from [224-255] shall be used as the destination MAC ID of a direct hnk UMCH. The 
source MAC ID shall identify the originator of the direct link UMCH. 

5.5.6.8 UDCH 

A MAC ID, a DLCC ID, a start pointer, number of LCH and a type field in an RG in the FCCH identify the UDCH for 
centralized mode. The DLCC ID is selected during connection setup or by a default value provided by the convergence 
layer. The connection setup procedure is described in TS 101 761-2 [5]. Both directions of a bi-directional UDCH shall 
use the same DLCC ID. 

In direct mode, an additional destination MAC ID is used to identify an outgoing cormection for the transmitting 
terminal and a source MAC ID identifies an incoming connection for the receiving terminal. It is permitted to have 
outgoing simplex connections with the same DLCC ID to different destination MAC IDs and to have incoming simplex 
connections with the same DLCC ID from different source MAC IDs. But between a source and destination MAC ID 
pair, both directions of a bi-directional UDCH shall use the same DLCC ID. 

NOTE: The UDCH is identified by the MAC ID(s), DLCC ID and the assigned capacity for LCHs in the RG in 
the FCCH. No MAC ID(s) or DLCC ID is included in the actually transmitted UDCH. 

5.5.6.9 LCCH 

A MAC ID, a DLCC ID, a start pointer, number of SCH and a type field in a RG in the FCCH identify the LCCH for 
centralized mode. Additional identification information is given in an SCH type field. In the case of RRs that are sent in 
the RCH, the LCCH is identified by an RCH type field, the source MAC ID, and the DLCC ID. 

Both directions of a bi-directional LCCH shall use the same DLCC ID. 

In direct mode, an additional destination MAC ID is used to identify an outgoing connection for the transmitting 
terminal, and a source MAC ID identifies an incoming connection for the receiving terminal. 

5.5.6.10 ASCH 

A set of ASCH specific RLC type field values in the RCH identifies ASCH RLC messages. Further information can be 
found in TS 101 761-2 [5]. 

5.5.7 Identification of transport cinannels 

5.5.7.1 BCH 

The BCH is identified by its location in the MAC frame. Further details can be found in clause 6. 

5.5.7.2 FCH 

In the case of a single sector, the FCH is identified by its location in a MAC frame. In the case of multiple sectors, the 
location of the FCH of each sector is indicated by a 12 bit pointer in the BCCH corresponding to this sector. 

5.5.7.3 ACH 

In the case of a single sector, the ACH is located in the MAC frame immediately following the FCH. In the case of 
multiple sectors, its location is indicated in the BCCH by a 12 bit pointer and the length of the FCH, see clause 6. 

5.5.7.4 LCH 

LCHs are identified by Resource Grant Information Elements (IE) in the FCCH and a set of rules, see clause 6. 

5.5.7.5 SCH 

SCHs are identified by Resource Grant Information Elements (IE) in the FCCH and a set of rules, see clause 6. 
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5.5.7.6 RCH 

The BCCH announces the location of the RCH. 



6 Radio transmission and reception functions 

6.1 Format of the transport channels 

This section describes the exact contents and formats of the transport channels. All bit representations of information 
fields are displayed such that the MSB appears on the left end. Fields that are for future use can have arbitrary values if 
no specific values are defined. 

6.1.1 Broadcast CHannel (BCH) format 

The BCH contains 120 bits. The content is the BCCH. 

6.1 .2 Frame CHannel (FCH) Format 

The FCH carries the FCCH. The basic structure of the FCH is shown in figure 9. The FCH shall be built of fixed size IE 
blocks. The AP or CC determines the number of blocks. Every IE block shall contain three lEs, each with a length of 8 
octets, and a CRC of length 24 bits which shall be calculated over the three preceding lEs. The rules for the calculation 
of the CRC and for the use of the FCH when building a MAC frame are described in the subsequent clauses. 











Multiple 


f 27 octets 
















FCH 














IE block 


CRC-24 


IE block 


CRC-24 




IE block 


CRC-24 




\^ 












IEi 


IE2 


IE3 








\ 








IE flag 






IE Type 




IE Info 





Figure 9: FCH structure 



The content of the IE is shown in table 4. Figure 10 shows the resulting transfer syntax. 
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Table 4: Contents of the FCH lEs 



Name 


Length (bits) 


Purpose 


IE-flag 


1 


Always set to one 

(Used for future purposes to make this structure 

expandable) 


IE-type 


4 


Identifies the IE type 

The mapping of the field is as follows 


IE-Type 


Purpose 


0000 


Downlink RG 


0001 


Uplink RG 


0010 


Direct link RG 


0011 


Future use 


0100 


Empty parts in the frame 


0101 


Padding IE 


0110-1111 


Future use 


IE Info 


59 


FCCH IE content | 





8 


7 


6 5 4 


3 


2 


1 


Octet 1 


IE flag 


IE type 




Octet 2 






FCCH IE content 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 



Figure 10: FCH transfer syntax 

The content of the FCH padding IE is not specified. 

6.1 .3 Access feedback CHannel (ACH) format 

The ACH carries the RFCH (see subclause 6.2). The ACH have a total size of nine octets. The format is identical to the 
SCH format and has a type field with the binary coding 01 10 at its beginning. The value of this type field shall not be 
used for SCH message types. 

6.1 .4 Long transport CHannel (LCH) format 

The LCH consists of 54 octets. The contents are DCCH, RBCH, UDCH, UBCH or UMCH messages. It contains a LCH 
PDU type field that is coded according to table 5. 

Tables: LCH type field 



LCH PDU type 


Purpose 


00 


Carries a UDCH, UBCH, UMCH, 
DCCH or RBCH message 


01 


Dummy LCH 


10 


Future use 


11 


Future use 



The transfer syntax for an LCH is given in figure 1 1 . 
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8 7 


6 


5 4 


3 


2 


1 


Octet 1 


LCH PDU type 




Payload 








Octet 2 




Octet 3 


Octet 4 


Octet 5 



Octet 50 




Octet 51 


Octet 52 


CRC-24 


Octet 53 


Octet 54 



Figure 11 : LCH transfer syntax 

NOTE: The RG in the FCCH defines which logical channel is to be transferred. 

6. 1 .5 Short transport CHannel (SCH) format 

The SCH consists of 9 octets. The SCH carries messages for various logical channels which themselves contain 
messages for different purposes. A type field distinguishes these message types. The allocation of identifiers in this type 
field is shown in table 6. 

Table 6: SCH type field 



SCH PDU Type 
MSB-LSB 


Purpose 


0000 


Reserved 


0001 


ARQ feedback 


0010 


Discarding 


0011 


RRfor uplink 


0100 


RLC to/from the AP/CC 


0101 


RRfor direct link 


0110 


Not allowed (used for ACH) 


0111 


RLC in DM (RBCH, DCCH) 


1000 


Encryption Seed (only in downlink RBCH) 


1001 


Dummy SCH 


1010-1111 


Reserved 



The content of the dummy SCH payload field is not specified. 

Table 7 shows the general SCH format. The general SCH transfer syntax is depicted in figure 12. 

Table 7: General contents of the SCH 



Name 


Bits 


Purpose 


MAC PDU Type 


4 


Determines the type of information in the SCH 


Info 


52 


Information transported in the SCH 


CRC 


16 


CRC-16 


Total 


72 





£75/ 



28 



ETSI TS 101 761-1 V1.1.1 (2000-04) 





8 


7 6 


5 


4 


3 


2 


1 


Octet 1 


MSB 


SCH PDU type 












Octet 2 










Octet 3 


Information field 


Octet 4 


Octet 5 


Octet 7 


Octet 8 


CRC-16 


Octet 9 



Figure 12: General SCH transfer syntax 

6.1 .6 Random CHannel (RCH) format 

The RCH consists of 9 octets. Its format is identical to the format of the SCH. The RCH does not carry all message 
types that are allowed for SCH. Table 8 shows the allowed SCH PDU type values for the RCH. 

Table 8: RCH type identifier 



SCH PDU Type 
MSB-LSB 


Purpose 


0000 


Reserved 


0001 


Not allowed (ARQ feedback) 


0010 


Not allowed (Discarding) 


0011 


RR for uplink 


0100 


RLC to the AP/CC 


0101 


RR for direct link 


0110 


Not allowed (ACH) 


0111 


Not allowed (RLC for direct mode) 


1000 


Not allowed (Encryption Seed) 


1001 


Not allowed (Dummy) 


1010-1111 


Reserved 



NOTE: In the above table the RCH PDU type uses the same mapping of the RCH PDUs as for SCH PDUs. 
Therefore the term SCH PDU type is used instead of RCH PDU type. 

6.2 Logical channel formats 

The following subclause shows the message formats of the logical channels. The contents are listed in a table together 
with a description of the meaning of the field contents. Where appropriate, the contents of the logical channels are 
described including the surrounding traffic channel contents in order to increase readability. 

6.2.1 BCCH message format 

The content of the BCCH and a description of the contents is given in table 9. The CRC in the end shall be calculated 
over the preceding 12 octets according to the algorithm given in subclause 6.6. 
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Table 9: Contents of the BCCH 



Name 


Bits 


Purpose 


Frame counter (scrambler seed) 


4 


Identifies which scrambling pattern shall be 
applied to the DLC PDU trains in the MAC frame. 
The counter shall be incremented by one modulo 
16 every MAC frame. The scrambling is 
described in TS 101 475 [4]. 


NET ID 


10 


Network identifier (see subclause 5.5). 


ARID 


10 


AP identifier (see subclause 5.5). The MT shall 
check the AP ID in each frame. If the AP ID is 
different from what the MT expects to receive, the 
MT shall not transmit anything in the frame. 


Sector ID 


3 


Identifies the used sector. Each sector is 
numbered from up to 7 and is increased by one 
for each sector. The BCHs are transmitted in the 
order according to their Sector ID. 

000 = First sector antenna (this number is also 
used for a single sector AP). 

001 = Second sector. 

111= Eighth sector. 


AP TX level 


4 


Identifies AP transmission power (see TS 101 
475 [4]). 


AP RX UL level 


3 


Identifies the expected AP reception power level. 
It covers both normal uplink data and RCH data 
(see TS 101 475 [4]). 


Pointer to FCH 


12 


A pointer to the FCH is needed in the case 
multiple sectors are used by the AP. The pointer 
is pointing to the ACH instead if the length of the 
FCH is set to zero for a sector (this means that 
the sector will not transmit any FCH). The 
reference point for the pointer is defined in 
subclause 6.3.5. 


Length of FCH 


4 


Identifies the number of IE blocks in the FCH. If 
length is set to zero for an sector, this means that 
the sector will not transmit any FCH 


PHY Mode of FCH 


2 


00 = BPSK, code rate 1/2. 
01-11= Future use. 


Pointer to RCH 


13 


Identifies the starting point of the RCHs. The 
reference point for the pointer is defined in 
subclause 6.3.5. 


Length of RCH 


5 


Identifies the number of RCHs. 

00000 = Future use 

00001 = 1 RCH in the frame 
00010 = 2 RCH in the frame 

11111=31 RCH in the frame 


RCH Guard space 


2 


Identifies the guard time used between the RCHs, 
see TS 101 475 [4] 


DL RBCH indicator 


1 


Indicates that the downlink RBCH will be sent in 
this frame. 


DST (Data to sleeping terminals) 


1 


Indicates whether the current MAC frame 
contains data for at least one sleeping terminal. 

= The frame does not contain data for sleeping 
terminals. 

1 = The frame contains data for sleeping 
terminals. For details, see TS 101 761-2 [5]. 


Uplink preamble 


1 


Indicate which preamble is used in the uplink. 

= Short 

1 = Long (see TS 101 475 [4]) 


Phase indicator 


4 


Indicates the phase according to which the 
AP/CC has been built. 
0001 = Phase 1 


AP traffic load indicator 


3 


Not used. May be set to any value 
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Name 


Bits 


Purpose 


Maximum power indicator 


1 


= The AP transmits with either its maximum 
power or its maximum power-3dB. 

1 = The AP does not transmit within the power 
range given above. 


Number of sectors 


3 


Identifies the number of sectors the AP uses. 

000 = Single sector. 

001 = Two sectors 

010 = Three sectors 

01 1 = Four sectors 

111= Eight sectors 


Future use 


10 


For future use 


CRC 


24 


CRC-24 


Total length 


120 





The transfer syntax of the BCCH is given in figure 13. 





8 




7 


6 




5 


4 


3 




2 


1 


Octet 1 


MSB 


Frame counter [n4, n 


3, n2, n.|] 


MSB 




Octet 2 






FCH pointer 


Octet 3 


MSB 


Length of FCH 




MSB 

FCH PHY mode 


DST 


DLRBCH 
ind 


Octet 4 


MSB 






APID 




Octet 5 




MSB 


AP TX Level 




MSB 


Octet 6 






NET ID 






Octet 7 


MSB 


Sector ID 




MSB 




Octet 8 








RCH pointer 


Octet 9 


MSB 


Length of RCH 


MSB 


AP RX level 


Octet 1 


MSB 


RCH Guard 
space 


MSB 


Number of sectors 


MSB 


AP traffic load ind 


Octet 1 1 


Preai 


nd 


Max Pow 
ind 


MSB Phase indicator 


Future use 


Octet 12 






Future use 






Octet 13 


CRC-24 


Octet 14 


Octet 1 5 



Figure 13: Transfer syntax of the BCCH 

The use of the pointers to the FCHs in the case of multiple sectors is illustrated in figure 14. 
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FCH pointer given 
^inBCCH of sector 1 



FCH pointer given in 
BCCH/of sector N 






PreamBCHl 



PreamBCHN 



PreamFCH-ACH 1 



/ 



RCH pointer given in 
BCCH of sector; 



PreamFCH-ACHN 



Other parts of the 
frame 



PreamRCHl 



PreamRCHn 



RCHs sector ; 



Reference point, see subclause 6.3.5 



Figure 14: Illustration of the use of the pointers in the BCCH 

6.2.2 FCCH information element contents and message formats 

6.2.2.1 IE for allocating resources for: RBCH, DCCH, UBCH, UMCH, and UDCH and 

LCCH for downlink and uplink 

Table 10 illustrates the structure of the IE that shall be used to allocate resources for the downlink transmission of 
RBCH, DCCH, UBCH, UMCH, UDCH and LCCH. 

Table 10: Format of RG IE for downlink allocation in centralized mode 



Fields 


Bits 


Purpose 


IE flag 


1 


Shall be set to 1. 


IE Type 


4 


0000 (downlink) 


MAC ID 


8 


Identifies which IVIAC ID the resource grant 
belongs to. 


DLCC ID 


6 


Identifies which DLCC ID the resource grant 
belongs to. 


Start Pointer 


13 


Identifies the starting point of transmission, see 
subclause 6.3.5. 


#SCH 


6 


Specifies the number of SCHs allocated for this 
particular DUC. 


RR poll 


1 


Future use. 


PHY mode SCH 


3 


Sets the PHY mode for the granted SCHs. 


#LCH 


8 


Specifies the number of LCH allocated for this 
particular DUC 


PHY mode LCH 


4 


Sets the PHY mode for the granted LCHs. 


Future use 


10 




Total: 


64 





The message content of RGs for the allocation of capacity in the uplink is shown in table 1 1 . This message can only be 
used for the allocation of DCCHs, UDCHs and LCCHs in uplink direction. 
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Table 11 : Format of RG IE for the uplink allocation in centralized mode 



Fields 


Bits 


Purpose 


IE flag 


1 


Shall be set to 1. 


IE Type 


4 


0001 (uplink). 


MACID 


8 


Identifies which MAC ID the resource grant 
belongs to. 


DLCC ID 


6 


Identifies which DLCC ID the resource grant 
belongs to. 


Start Pointer 


13 


Identifies the starting point of the transmission, 
see subclause 6.3.5. 


#SCH 


6 


Specifies the number of SCHs. Rules for the 
use are given in subclause 6.3.2.4. 


RR poll 


1 


Only valid for uplink RGs. Rules for the use are 
given in subclause 6.3.2.4. 


PHY mode SCH 


3 


Sets the PHY mode for the granted SCHs. 


#LCH 


8 


Specifies the number of LCHs allocated for this 
particular DUC. 


PHY mode LCH 


4 


Sets the PHY mode for the granted LCHs. 


Future use 


10 




Total: 


64 





The transfer syntax of the RG IE for uplink and downhnk is shown in figure 15. 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


IE flag 


MSB 


IE type 


MSB MAC ID 


Octet 2 


MSB 


MACID 


Future use 


Octet 3 


Future use 


MSB DLCC ID 


Octet 4 


DLCC ID 


MSB S 


>tart pointer 




Octet 5 






Start pointer 


Octet 6 


Future use 


MSB 


SCH PHY mode 


MSB 


LCH PHY mode 




Octet 7 


MSB 


#LCH 






Octet 8 


MSB 


#SCH 




RR poll 


Future use 



Figure 15: Transfer syntax of the RGs for up- and downlink in centralized mode 

The support of the RG lEs for uplink and downlink is mandatory for both APs/CCs and MTs. 

The possible PHY mode for the RBCH is fixed to BPSK with code rate Vi. All other logical channels announced with 
the above described RG may use all mandatory and, if agreed, optional PHY modes (see subclause 6.9). 

The AP/CC shall be responsible to select any of the mandatory and, if agreed, optional PHY modes for the downlink 
and uplink transmission. The PHY modes continuosly proposed by the MT should be considered as recommendations to 
the AP/CC when setting the PHY modes for the downlink transmission. The AP/CC shall itself determine which PHY 
modes are used in the uplink transmission. 

NOTE 1 : It is up to the scheduler in the AP/CC to determine the needed capacity for LCHs and SCHs. It is allowed 
that the scheduler allocates more LCHs and SCHs than have been requested or negotiated by the MTs. 

NOTE 2: The AP/CC is responsible to schedule the number of ARQ feedback messages that are to be transmitted in 
SCHs. 

6.2.2.2 IE for allocating resources for RBCH, DCCH, UBCH, UMCH, UDCH and 

LCCH in the direct link 

Table 12 illustrates the structure of the IE that shall be used to allocate resources for RBCHs, DCCHs, UBCHs, 
UMCHs, UDCHs and LCCHs in the direct link. 
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Table 12: Format of RG IE for direct link (optional feature) 



Fields 


Bits 


Purpose 


IE flag 


1 


Shall be set to 1. 


IE Type 


4 


0010 (direct link) 


Source MAC ID 


8 


Identifies the source MAC ID the resource grant 
belongs to. 


Destination IVIAC ID 


8 


Identifies the destination MAC ID the resource 
grant belongs to. 


DLCC ID 


6 


Identifies which DLCC ID the resource grant 
belongs to. 


Start Pointer 


13 


Identifies the starting point of the 
transmission/reception, see subclause 6.3.5. 


#SCH 


6 


Specifies the number of SCHs per DUC. Rules for 
the use are given in subclause 6.3.2.4. 


PHY mode SCH 


3 


Sets the PHY mode for the granted SCHs. 


#LCH 


8 


Specifies the number of LCHs per DUC. 


PHY mode LCH 


4 


Sets the PHY mode for the granted LCHs. 


Future use 


3 




Total: 


64 





The transfer syntax of the RG IE for direct link is shown in figure 16. 





8 


7 6 


5 


4 




3 


2 1 


Octet 1 


IE flag 


MSB IE type 


MSB Source MAC ID 


Octet 2 


MSB 


Source MAC ID 




MSB Destination MAC ID 


Octet 3 


MSB 


Destination MAC ID 




MSB DLCC ID 


Octet 4 


DLCC ID 


MSB 


Start pointer 


Octet 5 


Start pointer 


Octet 6 


Future use 


MSB SCH PHY mode 


MSB 


LCH PHY mode 


Octet 7 


MSB 


#LCH 




Octet 8 


MSB 


#SCH 




Future use 



Figure 16: Transfer syntax of RG for direct link 

The RG IE for DiL includes an additional field, the Destination MAC ID, which indicates the destination of the simplex 
transmission. The support of this IE is optional for both AP/CC and MT. If the use of direct mode has been agreed 
between MT and AP/CC in the negotiation during association, this message and according rules shall be supported. 

The possible PHY mode for the RBCH is fixed to BPSK with code rate Vi. All other logical channels announced with 
the above described RG may use all mandatory and, if agreed, optional PHY modes (see subclause 6.9). 

If the AP/CC is involved in DM communication itself, the first LCHs and SCHs in the DiL phase shall be granted to the 
AP/CC to minimize RF transceiver turn-arounds. 

All LCHs and SCHs used by the same transmitting MT to different receiving MTs shall be granted consecutively 
without interruption in order to avoid unnecessary RF transceiver turn-arounds. This means that, in DM the transmission 
of LCHs and SCHs from one MT to different destinations shall not be interrupted by the transmission of another MT. 

NOTE 1 : It is up to the scheduler in the AP/CC to determine the needed capacity for LCHs and SCHs. It is allowed 
that the scheduler allocates more LCHs and SCHs than have been requested or negotiated by transmitting 
MT. 

NOTE 2: The AP/CC is responsible to schedule the number of DiL ARQ feedback messages that are to be 
transmitted in SCHs. 

The AP/CC is responsible to select any of the mandatory and, if agreed, optional PHY modes for the direct link 
transmission. The receiving entity of a DiL connection proposes a PHY mode for SCH and LCH in the RR for DiL. The 
RR for DiL shall be sent in the uphnk in the DCCH via an SCH or RCH. 
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6.2.2.3 



IE for empty parts in the MAC frame 



This IE is used by the AP/CC to announce a fraction of the MAC frame that is not used for any traffic. The AP/CC shall 
send this message only when it has ordered at least one MT to make DPS measurements in the current frame. The DPS 
measurement procedures are described in TS 101 761-2 [5]. The MT performs measurements of the interference from 
other APs/CCs in the announced empty parts. The content of this IE is described in table 13. 

Table 13: IE for empty parts in the MAC frame 



Name 


Bits 


Purpose 


IE flag 


1 


Set to 1 


IE type 


4 


0100 


Start pointer 


13 


Identify the start of an empty part 


Stop pointer 


11 


Identify the stop of the empty part. The 
pointer is relative the start pointer for the 
empty part. 


Start pointer 


13 


Identify the start of an empty part 


Stop pointer 


11 


Identify the stop of the empty part. The 
pointer is relative the start pointer for the 
empty part. 


Future use 


11 




Total 


64 





The transfer syntax of the RG IE for empty parts is shown in figure 17. 





8 


7 


6 




5 4 


3 


2 


1 


Octet 1 


IE flag 


IE type 




Octet 2 










Future use 


Octet 3 


MSB 


Stop-pointer 








Octet 4 


MSB Start pointer 


Octet 5 










Octet 6 


MSB 


Stop-pointer 








Octet 7 


MSB Start pointer 


Octet 8 











Figure 17: Transfer Syntax of the RG for empty parts in a MAC frame 

The support of this IE is mandatory for both APs/CCs and MTs. 



6.2.2.4 



IE for padding 



The IE for padding shall be used to fill an PCH IE block if the total number of RGs does not end up in a multiple of 
three (i.e. the RGs can not itself fill up the IE blocks). The IE format is shown in table 14. 

Table 14: IE for padding 



Name 


Bits 


Purpose 


IE flag 


1 


Set to 1 . 


IE type 


4 


0101 


Future Use 


59 


Unused 


Total 


64 
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The transfer syntax of the RG IE fields is shown in figure 18. 





8 


7 


6 5 4 


3 


2 


1 


Octet 1 


IE flag 


IE type 




Octet 2 






Future use 


Octet 3 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 



Figure 18: Transfer Syntax of the RG for empty parts in a lUIAC frame 

The support of this IE is mandatory for both MTs and APs/CCs. 

6.2.3 RFCH message format 

The contents of the RFCH are shown in table 15. 

Table 15: contents of the RFCH 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0110 


RFCH type 


4 


Defines the type of the RFCH message. 

0000 = RFCH for the RCH 

0001 - 1 1 1 1 = For future use 


RCH1 


1 


Feedback for the RCH1 of the previous 

frame 

= No success (collision or idle) 

1= success 








RCH31 


1 


Feedback for the RCH31 of the previous 

frame 

= No success (collision or idle) 

1= success 


Future Use 


17 


For future use 


CRC 


16 


CRC-16 


Total 


72 





Figure 19 shows the transfer syntax of the RFCH. 
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8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


MSB 


SCH PDU type 




RFCH type 


Octet 2 


RCH8 


RCH7 


RCH6 


RCH5 


RCH4 


RCH3 


RCH2 


RCH1 


Octet 3 


RCH16 


RCH15 


RCH14 


RCH13 


RCH12 


RCH11 


RCH10 


RCH9 


Octet 4 


RCH24 


RCH23 


RCH22 


RCH21 


RCH20 


RCH19 


RCH18 


RCH17 


Octet 5 


Fut. use 


RCH31 


RCH30 


RCH29 


RCH28 


RCH27 


RCH26 


RCH25 


Octet 6 


Future use 


Octet 7 


Octet 8 


CRC-16 


Octet 9 



Figure 19: Transfer syntax of the RFCH 

The support and the use of this message is mandatory for the AP/CC. MTs shall be able to interpret this message. The 
feedback to the use of the RCHs in MAC frame / is transmitted in the ACH in MAC frame i+1, as illustrated in 
figure 20. 



MAC frame . 



..>V_ 



RCH 

1 



RCH 

2 



RCH 
K 



1 



Mac frame i+1 



ACH 



Figure 20: Illustration of the operation of the ACH 



6.2.4 RBCH message formats 



6.2.4.1 



RBCH message in an LCH 



Downlink and direct link RBCH messages in LCHs have the same format as the DCCH messages in downlink, and 
direct link phase, respectively, see subclause 6.2.5. The support of the downlink RBCH in an LCH is mandatory for 
APs/CCs and MTs. The support of the direct hnk RBCH in an LCH is optional for MTs and APs/CCs. If the use of 
direct mode has been agreed between MT and AP/CC in the negotiation during association, the direct link RBCH in an 
LCH shall be supported. 



6.2.4.2 



Downlink RBCH message in an SCH 



6.2.4.2.1 



Messages from the PLC 



RBCH messages in SCHs have generally the same format as DCCH messages in a downlink SCH, see subclause 6.2.5.2. 
The transmission of the encryption seed is an exception and is described in the subsequent clause. The support of the 
RBCH in a downlink SCH is mandatory for APs/CCs and MTs. 

6.2.4.2.2 Encryption seed 

The contents of the RBCH message with the encryption seed in an SCH are shown in table 16. 

Table 16: Contents of the downlink RBCH message with the encryption seed in an SCH 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


1000 


Info 


52 


Encryption seed (see subclause 6.7) 


CRC 


16 


CRC-16 


Total 


72 
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Figure 21 shows the transfer syntax of the downhnk RBCH message with the encryption seed in an SCH. 





8 


7 6 


5 




4 


3 


2 


1 


Octet 1 


MSB 


SCH PDU type 






MSB 








Octet 2 








Seed 


Octet 3 




Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


CRC-16 


Octet 9 



Figure 21 : Transfer syntax of the downlink RBCIH message with the encryption seed in an SCIH 

The support of this message is mandatory for both MTs and APs. 



6.2.4.3 



Direct link RBCH message in an SCH 



Direct link RBCH messages in SCHs have the same format as the DCCH messages in direct link SCHs, see 
subclause 6.2.5.4. The support of the direct link RBCH in an SCH is optional for MTs and APs/CCs. If the use of direct 
mode has been agreed between MT and AP/CC in the negotiation during association, the direct link RBCH in an SCH 
shall be supported. 

6.2.5 DCCH message formats 

DCCH message can be mapped on LCHs, SCHs or RCHs, depending on their length. The mapping procedure is out of 
the scope of the present document. 

Different message formats are used for uplink, downlink and direct link RLC messages in an SCH. The type field for 
uplink and downlink RLC messages is identical. The message formats for uplink DCCHs transmitted in SCHs and in 
RCHs are identical. 



6.2.5.1 



DCCH message in an LCH 



The message format for a DCCH message in an LCH is identical to the message format of the UDCH, see 
subclause 6.2.8. The support of this message is mandatory for APs/CCs and MTs. The sequence number shall be 
increased by one for every RLC message sent in an LCH. 

6.2.5.2 DCCH message in a downlink SCH 

The contents of the downlink RLC message in an SCH are shown in table 17. 

Table 17: Contents of the downlink RLC message in an SCH 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0100 


Future use 


7 


Future use 


RLC message 


45 


RLC message contents (see 
TS 101 761-2 [5]). 


CRC 


16 


CRC-16 


Total 


72 





Figure 22 shows the transfer syntax of the downlink RLC message in an SCH. 
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8 


7 


6 


5 


4 


3 2 


1 


Octet 1 


MSB 


SCH PDU type 




Future use 


Octet 2 


RLC message 


Octet 3 


Future use 


RLC message 


Octet 4 








Octet 5 


Octet 6 


Octet 7 


Octet 8 


CRC-16 


Octet 9 



Figure 22: Transfer syntax of the downlink RLC message in an SCIH 

This support of this message is mandatory for APs/CCs and MTs. 

6.2.5.3 DCCH message in an uplink SCH or RCH 

The DCCH messages in an uphnk SCH or RCH are either resource request messages or uplink RLC messages. 

The message format for a resource request message in an SCH or RCH is identical to the message format of the resource 
request message for LCCH, see subclause 6.2.9. 1 . 

The contents of the uplink RLC message in an SCH or RCH are shown in table 18. 

Table 18: Contents of the uplink RLC message in an SCH or RCH 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0100 


LCH PHY mode 


4 


Proposed PHY mode for 
downlink LCHs related to this 
DLCC ID, i.e. DLCC ID=0. 


SCH PHY mode 


3 


Proposed PHY mode for 
downlink SCHs related to this 
DLCC ID, i.e. DLCC ID=0. 


RLC message 


45 


RLC message contents (see 
TS 101 761-2 [5]). 


CRC 


16 


CRC-16 


Total 


72 





Figure 23 shows the transfer syntax of the uplink RLC message in an SCH or RCH. 





8 


7 6 


5 


4 


3 2 


1 


Octet 1 


MSB 


SCH PDU type 




LCH PHY mode 


Octet 2 


RLC message 


Octet 3 


SCH PHY mode 


MSB 

RLC message 


Octet 4 






Octet 5 


Octet 6 


Octet 7 


Octet 8 


CRC-16 


Octet 9 



Figure 23: Transfer syntax of the uplink RLC message in an SCH 
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The support of these messages is mandatory for APs/CCs and MTs. 

6.2.5.4 DCCH message in a direct link SCH 

The contents of the direct link RLC message in an SCH are shown in table 19. 

Table 19: Contents of the direct link RLC message in an SCH 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0111 


RLC message 


52 


RLC message contents (see 
TS101 761-2 [5]) 


CRC 


16 


CRC-16 


Total 


72 





Figure 24 shows the transfer syntax of the direct link RLC message in an SCH. 





8 


7 6 


5 


4 


3 


2 


1 


Octet 1 


MSB 


SCH PDU type 












Octet 2 










Octet 3 


RLC message 


Octet 4 


Octet 5 


Octet 6 


Octet 7 


Octet 8 


CRC-16 


Octet 9 



Figure 24: Transfer syntax of the direct link RLC message in an SCH 

The support of this message is optional for MTs and APs/CCs. If the use of direct mode has been agreed between MT 
and AP/CC during the negotiation during association, this message shall be supported. 

6.2.6 UBCH message formats 

This message shall be sent either in the downlink (by an AP or CC) or direct link (by an MT). It has the same format as 
UDCH messages. The error control mechanisms for broadcast traffic is described in subclause 6.4. 

6.2.7 UMCH message formats 

This message shall be sent either in the downlink (by an AP or CC) or direct link (by an MT). It has the same format as 
UDCH messages. The treatment of multicast traffic is described in subclause 6.5. 

6.2.8 UDCH message formats 

The contents of the UDCH message is shown in table 20. UDCHs are subject to error control mechanisms. These 
mechanisms are defined in subclause 6.4. 
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Table 20: Contents of the UDCH 



Name 


Bits 


Purpose 


LCH PDU type 


2 


See table 1 


SN 


10 


Sequence number (provided by EC function) 


Payload 


396 


Payload field 


CRC 


24 


CRC-24 


Total: 


432 





The transfer syntax for a UDCH in an LCH is given in figure 25. 





8 7 


6 


5 


4 3 2 


1 


Octet 1 


MSB LCH PDU type 


MSB 




Sequence number 




Octet 2 


Sequence number 




MSB 




Octet 3 








Octet 4 


Payload 


Octet 5 



Octet 50 




Octet 51 


Octet 52 


CRC-24 


Octet 53 


Octet 54 



Figure 25: UDCH transfer syntax 

The support of this message is mandatory for APs/CCs and MTs. 

6.2.9 LCCH message formats 

6.2.9.1 Resource Request message formats 

6.2.9.1 .1 Resource Request message for the uplink 

Resource request messages for the uphnk phase can be transmitted in an SCH or RCH. The contents of the RR message 
is shown in table 21. 
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Table 21 : Contents of the RR message for uplink 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0011 


PHY mode SCH 


3 


Proposed PHY mode for downlink 
SCHs related to this DLCC ID. 
The coding is given in 
subclause 6.9 


PHY mode LCH 


4 


Proposed PHY mode for downlink 
LCHs related to this DLCC ID. The 
coding is given in subclause 6.9 


MAC ID 


8 


MAC ID. 


DLCC ID 


6 


DLC connection ID. 


#SCH 


5 


Number of SCHs requested for 
the particular DUC. Rules for the 
use are described in 
subclause 6.3.2.8. 


#LCH 


10 


Number of LCHs requested for the 
particular DUC, but not more than 
the FC limit. Rules for the use are 
described in subclause 6.3.2.8. 


Error indication 


3 


See subclause 6.3.7. 


RSSO sample 


6 


The sample shall be taken in the 
current frame. See TS 101 475 
[41. 


Retry Bit 


1 


Represents whether this specific 
RCH/SCH content was 
transmitted once or more than 
once. 

= first attempt 

1 = more than one attempt 
See subclause 6.3.2.8 


ARQ feedback message 
request bit (ARB) 


1 


See subclause 6.3.2.8 


Future use 


5 


Future use. 


CRC 


16 


CRC-16 


Total 


72 





Figure 26 shows the transfer syntax of the uphnk RR message 





8 


7 


6 5 


4 


3 


2 


1 


Octet 1 


MSB 


SCH PDU type 


LCH PHY mode 


Octet 2 


MSB 


MAC ID 


Octet 3 


Future use 


MSB RSSO sample value 


Octet 4 


MSB 


DLCC ID 


ARB 


Future use 


Octet 5 


Future 


use 


Error indication 


SCH PHY mode 


Octet 6 


MSB 




#LCH 


Octet 7 




MSB #SCH 


Retry bit 


Octet 8 


CRC-16 


Octet 9 



Figure 26: Transfer syntax of the uplink RR message 

Rules for the use of this message are given in subclause 6.3.2.8. 
The support of this message is mandatory for APs/CCs and MTs. 
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6.2.9.1.2 



Resource Request message for the direct link 



This message is transmitted from the MT to the AP/CC in the uplink and can be mapped to an SCH or RCH. The 
contents of the RR message for direct link is shown in table 22. 

Table 22: Contents of the RR message for direct link 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0101 


PHY mode SCH 


3 


Proposed PHY mode for direct linl< 
SCHs for tlie given DLCC ID 
(simplex). The coding is given in 
subclause 6.9 


PHY mode LCH 


4 


Proposed PHY mode for incoming 
direct link LCHs related to this 
DLCC ID (simplex). The coding is 
given in subclause 6.9. 


Source MAC ID 


8 


Transmitting MT MAC ID. 


Destination MAC ID 


8 


Receiving MT MAC ID. 


DLCC ID 


6 


DLC connection ID. 

DLCC ID = is used to indicate 

the request for DiL DCCHs. 


#SCH 


5 


Number of SCHs requested for 
the particular DUC. Rules for the 
use are described in 6.3.2.8. 


#LCH 


10 


Number of LCHs requested for the 
particular DUC, but not more than 
the FC limit. Rules for the use are 
described in 6.3.2.8. 


Error indication 


2 


See subclause 6.3.7 


Retry Bit 


1 


Represents whether this specific 
RCH/SCH content was 
transmitted once or more than 
once. 

= first attempt 

1 = more than one attempt 
See subclause 6.3.2.8 


ARQ-feedback message 
request bit (ARB) 


1 


See subclause 6.3.2.8 


Future use 


4 


Future use. 


CRC 


16 


CRC-16. 


Total 


72 





Figure 27 shows the transfer syntax of the RR message for direct link. 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


MSB 


SCH PDU type 


LCH PHY mode 


Octet 2 


MSB 


Source MAC ID 




Octet 3 


MSB 


Destination MAC ID 




Octet 4 


MSB 


DLCC ID 




ARB 


Future use 


Octet 5 


Future use 


Error indication 


SCH PHY mode 


Octet 6 


MSB 




#LCH 




Octet 7 




MSB #SCH 


Retry bit 


Octet 8 


CRC-16 


Octet 9 



Figure 27: Transfer syntax of the RR message for direct link 

Rules for the use of this message are given in subclause 6.3.2.8. 
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The PHY mode proposed in RRs for DiL are related to DiL connections. For proposing a PHY mode for a downlink 
DCCH, an RR for the uplink DCCH is used as described in subclause 6.2.9.1.1. 

The support of this message is optional for MTs and APs/CCs. If the use of direct link has been agreed between MT and 
AP/CC in the negotiation during association, this message shall be supported. 



6.2.9.2 



ARQ message formats 



6.2.9.2.1 



ARQ feedback message format in the uplink phase 



ARQ feedback messages in the uplink phase shall only be transmitted in SCHs that have been granted for a specific 
DUC. Since no further addressing information is given in the ARQ feedback message, this is necessary in order to create 
an unambiguous relation between the DUC and the ARQ feedback messages. In particular, ARQ messages shall not be 
transmitted in RCHs. The content of the uplink ARQ feedback message is shown in table 23. More detailed explanations 
on the fields, meaning, and related rules are given in subclause 6.4. 

Table 23: Contents of the uplink ARQ feedback message 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0001 


LCH PHY mode 


4 


Proposed PHY mode for downlink 
LCHs related to this DLCC ID. The 
coding is given in subclause 6.9. 


SCH PHY mode 


3 


Proposed PHY mode for downlink 
SCHs related to this DLCC ID. 
The coding is given in subclause 
6.9. 


FC 


1 


When set to 1 , indicates that flow 
control is active. 


ABIR 


1 


When set to 1 , indicates that more 
SCH bandwidth is needed by the 
receiver for the signalling of ARQ 
feedback. 


CAI 


1 


When set to 1 , indicates that 
BIVIB1 contains a CumAck. 


Future use 


1 


Future use. 


BMN1 


7 


Block Number of the Bit IVlap 
Block 1 . Absolute block number. 


BMB1 


8 


Bit IVlap Block 1 . 


BMN2 


5 


Block Number of the Bit IVlap 
Block 2. Relative to BMN1. 


BMB2 


8 


Bit Map Block 2. 


BMN3 


5 


Block Number of the Bit IVlap 
Block 3. Relative to BIVIN2. 


BMB3 


8 


Bit IVlap Block 3. 


CRC 


16 


CRC-16 


Total 


72 





Figure 28 shows the transfer syntax of the uplink ARQ feedback message. 
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8 




7 


6 


5 


4 


3 2 


1 


Octet 1 


MSB 


SCH PDU type 




LCH PHY mode 


Octet 2 


CAI 


MSB 


BMN1 






Octet 3 


MSB 




BMB1 






Octet 4 


SCH PHY mode 


MSB 


BMN2 




Octet 5 


MSB 




BMB2 






Octet 6 


FC 


ABIR 


Future use 


MSB 


BMN3 




Octet 7 


MSB 




BMB3 






Octet 8 


CRC-16 


Octet 9 



Figure 28: Transfer syntax of the uplink ARQ feedbacit message 

The treatment of this PDU is described in subclause 6.4. The support of this message is mandatory for AP/CC and MT. 

EXAMPLE: PDUs with sequence number 0-6 have been correctly received at the receiver. PDU with sequence 

number 7 is erroneous. The receiver then sets BMNl equal to and BMBl equal to [1 1 1 1 11 10]. 

NOTE: The bit representation given above is such that the MSB represents the lowest sequence number of a bit 
map block. 

6.2.9.2.2 ARQ feedback message format in the downlink and direct link phase 

ARQ feedback messages in the downlink and direct link phase shall only be transmitted in SCHs that have been granted 
for a specific DUC of the respective link. Since no further addressing information is given in the ARQ message, this is 
necessary in order to create an unambiguous relation between the DUC and the ARQ messages. The content of the 
downlink and direct link ARQ feedback message is shown in table 24. More detailed explanations on the fields, 
meaning, and related rules are given in subclause 6.4. 

Table 24: Contents of the downlink and direct link ARQ feedback message 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0001 


Future use 


9 


Future use. 


FC 


1 


When set to 1 , indicates that 
flow control is active. 


CAI 


1 


When set to 1 , indicates that 
BMBl contains a CumAck. 


BMN1 


7 


Block Number of the Bit IVIap 
Block 1 . Absolute block number. 


BMB1 


8 


Bit Map Block 1 . 


BMN2 


5 


Block Number of the Bit Map 
Block 2. Relative to BMNL 


BMB2 


8 


Bit Map Block 2. 


BMN3 


5 


Block Number of the Bit Map 
Block 3. Relative to BMN2. 


BMB3 


8 


Bit Map Block 3. 


CRC 


16 


CRC-16 


Total 


72 





Figure 29 shows the transfer syntax of the downlink and direct link ARQ feedback message. 



£75/ 



45 



ETSI TS 101 761-1 V1.1.1 (2000-04) 





8 


7 6 


5 


4 


3 2 


1 


Octet 1 


MSB 


SCH PDU type 




Future use 


Octet 2 


CAI 


MSB 


BMN1 






Octet 3 


MSB 




BMB1 






Octet 4 


Future use 


MSB 


BMN2 




Octet 5 


MSB 




BMB2 






Octet 6 


FC 


Future use 


MSB 


BMN3 




Octet 7 


MSB 




BMB3 






Octet 8 


CRC-16 


Octet 9 



Figure 29: Transfer syntax of the downlink and direct link ARQ feedback message 

The treatment of this PDU is described in subclause 6.4. The bit representation of the bit map blocks is the same as in 
the uplink ARQ feedback message. 

The support of the downUnk ARQ feedback message is mandatory for MT and AP/CC. 

The support of the direct link ARQ feedback message is optional for MT and AP/CC. If the use of the DM features have 
been agreed between MT and AP/CC in the negotiation during association, this message shall be supported. 



6.2.9.2.3 



Discard message format in the uplink phase 



Discard messages in the uplink phase shall only be transmitted in SCHs that have been granted for a specific DUC. 
Discard messages can only be sent for connections using the acknowledged mode in uplink. The content of the uplink 
discard message is shown in table 25. More detailed explanations on the fields, meaning, and related rules are given in 
subclause 6.4. 

Table 25: Contents of the uplink discard message 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0010 


PHY mode SCH 


3 


Proposed PHY mode for downlink 
SCHs related to this DLCC ID. 
The coding is given in subclause 
6.9. 


PHY mode LCH 


4 


Proposed PHY mode for downlink 
LCHs related to this DLCC ID. The 
coding is given in subclause 6.9. 


Discard Sequence Number 


10 


Indicates which PDUs the receiver 
shall discard. 


Repeated Discard 
sequence Number 


10 


Duplicated Discard sequence 
number. 


#SCH 


5 


Number of SCHs required for this 
particular DUC. 


#LCH 


10 


Number of LCHs required for this 
particular DUC, but not more than 
the FC limit. Rules for the use are 
described in 6.3.2.8. 


Error indication 


3 


See subclause 6.3.7. 


RSSO sample 


6 


The sample shall be the one taken 
in the current frame. See 
TS101 475 [41 


Retry Bit 


1 


See subclause 6.3.2.8 


CRC 


16 


CRC-16 


Total 


72 





Figure 30 shows the transfer syntax of the uplink discard message. 
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8 7 


6 5 


4 


3 2 


1 


Octet 1 


MSB SCH PDU type 


LCH PHY mode 


Octet 2 


MSB 


Discard sequence number 


Octet 3 




MSB RSSO sample value 


Octet 4 


MSB 


Repeated Discard sequence number 


Octet 5 




Error Indication 


SCH PHY mode 


Octet 6 


MSB 


#LCH 


Octet 7 




MSB #SCH 


Retry bit 


Octet 8 


CRC-16 


Octet 9 













Figure 30: Transfer syntax of the uplink discard message 

The uplink discard message contains fields that are defined in the RR message, e.g. # SCH, # LCH. The rules and 
restrictions for these fields are given in subclause 6.3.2.8. 

The support of this message is mandatory for AP/CC and MT. 

6.2.9.2.4 Discard message format in the downlink and direct link phase 

Discard messages in the downlink and direct link phase shall only be transmitted in SCHs that have been granted for a 
specific DUC of the respective link. Discard messages can only be sent for connections using the acknowledged or 
repetition error control mode. The content of the downlink and direct link discard message is shown in table 26. More 
detailed explanations on the fields, meaning, and related rules are given in subclause 6.4. 

Table 26: Contents of the downlink and direct link discard message 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0010 


Discard sequence Number 


10 


Indicates which PDUs the receiver 
shall discard. 


Repeated Discard 
sequence Number 


10 


Duplicated Discard sequence 
number. 


Future use 


32 


Future use 


CRC 


16 


CRC-16 


Total 


72 





Figure 3 1 shows the transfer syntax of the downlink and direct link discard message. 





8 


7 


6 5 


4 3 2 


1 


Octet 1 


MSB 


SON PDU type 


Future use 


Octet 2 


MSB 




Discard sequence number 




Octet 3 




Future use 


Octet 4 


MSB 




Repeated Discard sequence number 




Octet 5 








Octet 6 






Future use 


Octet 7 




Octet 8 


GRG-16 


Octet 9 



Figure 31 : Transfer syntax of the downlink and direct link discard message 
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The support of the downhnk discard message is mandatory for AP/CC and MT. The support of the direct link discard 
message is optional for MTs and APs/CCs. If the use of the DM features has been agreed between MT and AP/CC in the 
negotiation during association, this message shall be supported for direct link. The handling of the fields is explained in 
subclauses 6.3.2.8 and 6.4. 

6.2. 1 ASCH message format 

The content of an ASCH message is shown in table 27. The ASCH message is mapped to an RCH. The contents of the 
payload are generated by the RLC and are described in TS 101 761-2 [5]. 

Table 27: Contents of ASCH message in the RCH 



Name 


Bits 


Purpose 


SCH PDU Type 


4 


0100 


LCH PHY mode 


4 


Proposed PHY mode for downlink 
LCHs transporting DCCH. The 
coding is given in subclause 6.9. 


SCH PHY mode 


3 


Proposed PHY mode for downlink 
SCHs transporting DCCH. The 
coding is given in subclause 6.9. 


RLC message 


45 


RLC message, see 
TS101 761-2 [51. 


CRC 


16 


CRC-16 


Total 


72 





Figure 32 shows the transfer syntax of the uplink RLC message in an SCH or RCH. 





8 


7 


6 


5 


4 


3 2 


1 


Octet 1 


MSB 


SCH PDU type 




LCH PHY mode 


Octet 2 


RLC message 


Octet 3 


SCH PHY mode 


RLC message 


Octet 4 








Octet 5 


Octet 6 


Octet 7 


Octet 8 


CRC-16 


Octet 9 



Figure 32: Transfer syntax of uplinit RLC messages in SCHs 

The support of this message is mandatory for both MTs and APs/CCs. 

6.3 MAC protocol 

The MAC protocol is based on the information elements and their formats given in the previous clause. 

6.3.1 MAC operation 

The role of the MAC layer is to build valid TDMA/TDD MAC frames. This involves the following functions and 
operations: 

a scheduler, centralized in the AP, or CC, which determines the frame composition according to the rules defined 
in subclause 6.3.2. It is assumed that the scheduler uses the information obtained from MTs through RRs and the 
status of its own downlink transmission buffers to compose the frame; 
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a transmission and reception process in the AP/CC and the MTs that transmits and receives PDUs in accordance 
with the MAC frame defined by the AP/CC, and maps logical channels onto transport channels; 

- MAC entities shall exchange control (signalling) information such as the frame composition in the FCCH 

(AP/CC to MTs), feedback for the contention channel (AP/CC to MTs) and resource requests (MTs to AP/CC), 
through specific transport channels. 

6.3.1 .1 Access Point MAC Operation 

The AP/CC operation is the following: 

The AP/CC shall calculate the frame composition, prepare and transmit the BCH, FCH and ACH according to 
the rules specified in subclause 6.3.2. A BCH contains the position and length of its associated FCH as well as 
the position and the number of the RCHs. The FCH lEs contain resource grants for the transmission of PDUs in 
the RBCH, the UDCHs, the UBCHs, the UMCHs, the DCCH and the LCCHs. The FCH IBs can also contain an 
indication of empty parts of a frame, see subclause 6.2.2.3. The identification of the logical channels associated 
to a resource grant is specified in subclause 5.5. The type of the IE identifies whether the grant is in an uplink 
phase, downlink phase, direct link phase or an empty part of the frame. 

The AP/CC prepares an ACH (RCH feedback) for every sector. The ACH is either part of the broadcast PDU 
train (single sector AP) or part of the FCH-ACH-PDU train (multiple sector AP), see subclause 6.9. 

The AP/CC transmits PDUs from logical channels in the downlink phase according to the current frame 
composition and the rules defined in subclause 6.3.2. If the CC itself is involved in DM operation, it also 
transmits PDUs from logical channels in the direct link phase. 

The AP/CC receives and processes the PDUs transmitted by the MTs in the uplink phase. If a CC itself is 
involved in DM operation, it also receives and processes the PDUs meant for the CC which are transmitted by 
another MT in the direct link phase. 

The AP/CC receives and processes PDUs transmitted by the MTs in the RCH. 

6.3.1 .2 MT MAC Operation 

MT operation is the following: 

the MT receives and processes the BCH and the FCH and evaluates the FCCH with respect to the logical and 
transport channels relevant for it; 

the MT shall evaluate the ACH if it has used the RCH in the previous frame; 

the MT receives and processes the PDUs transmitted by the AP/CC in the downlink phase in CM, and/or by other 
MTs in the direct link phase in DM, in accordance with the frame structure contained in the FCH; 

the MT transmits PDUs from logical channels in the uplink phase in CM, and/or in direct link phase in DM, in 
accordance with the frame structure and the rules defined in subclause 6.3.2; 

the MT may access the RCH. 

6.3.2 Rules for the composition of MAC frames 

The following rules exist for the composition of MAC frames: 

6.3.2.1 BCH 

• A sequence of BCHs is sent at the beginning of the MAC frame. The number of BCHs is equal to the number of 
sectors used by the AP. PHY layer preambles are added according to the rules specified in subclause 6.9. BCHs are 
transmitted according to the ascending sector ID number, i.e. BCH having a sector ID equal to shall be 
transmitted first, the BCH with sector ID equal to 1 next and so forth. 

• A single BCH is used per sector. 
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• BCHs are transmitted periodically every 2 ms, except in cases where the AP is performing its own measurements 
related to the DFS procedure, see TS 101 761-2 [5]. 

• BCHs shall be transmitted using BPSK and coding rate Vi. 



6.3.2.2 



FCH 



• The FCH shall follow directly after the BCH in the case of one sector. In the case of more than one sector, a pointer 
shall be used in the BCCH to identify the starting point of the FCH. If the FCH does not exist, the starting point in 
the BCCH shall identify the location of the ACH. 

• In the case the numbers of sectors field in the BCCH is set to 0, a single sectored antenna is applied and the FCH 
shall follow directly after the BCH without any physical layer preamble. The pointer in the BCCH shall still point to 
the location of the FCH. 

• If a single sector is used, the FCH shall be present and have a minimum length of 36 )is. If there are not enough 
information elements to fill the FCH, one or more padding IBs shall be inserted. The minimum length of the FCH is 
in the case where multiple sectors are used. FCH with length shall be used for each sector where no downlink, 
uplink or direct link PDU trains are allocated in FCCH. 

• Whenever padding IBs are to be inserted, they shall be allocated at the end of the IB blocks. 

• Not more than one FCH per sector per MAC frame shall be transmitted. 

• Information elements shall be ordered in the FCH according to the order of their occurrence in the MAC frame, i.e. 
with increasing start pointer values (see figure 33). An exception is the information element for empty parts which 
contains two start pointers. For this IB the first start pointer shall be used for the purpose of ordering the IBs in the 
FCH. Not more than one RG shall be used per DUC per direction per FCH. The ordering shall be valid individually 
for each sector. 




FCH 

Figure 33: An illustration of the order of the lEs in the FCH and their occurence in the MAC frame 

• The use of the RR polling bit in RG messages is mandatory for APs/CCs in CM, i.e. the bit shall be set when the 
AP/CC polls for RRs for the uplink. MTs shall be able to interpret it correctly. The rules for the use of SCHs given 
in subclause 6.3.2.4 shall apply. 

• Whenever the AP/CC wants to poll for RRs for the direct hnk, it shall schedule uphnk SCHs with DLCC ID=0 (i.e 
uplink DCCHs) for the related MT, see subclause 6.3.2.4. 



6.3.2.3 



ACH 



• The AP/CC prepares an ACH (RCH feedback) for every sector. The ACH is either part of the broadcast PDU train 
(single sector AP) or part of the FCH-ACH-PDU train (multiple sector AP), see subclause 6.9. 

• The ACH shall use BPSK and coding rate V2. 
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• The ACH shall contain feedback to the RCHs of the previous frame 

• No explicit resource grant is needed for the ACH. 

• An ACH that has not been received correctly, for whatever reason, shall lead to a behaviour of an MT equal to that 
for an unsuccessful access attempt to an RCH and shall result in a new contention cycle, see subclause 6.3.3. 

6.3.2.4 SCH 

The way SCHs are granted for uplink and downlink is described in subclause 6.2.2. 1 . The way SCHs are granted for 
direct link is described in subclause 6.2.2.2. The following rules shall apply to the use of SCHs granted for LCCH or 
DCCH: 

The uplink SCHs granted for a particular DLCC ID > (i.e. not the DCCH) shall not be used for messages other than 
RR messages for this particular DUC, ARQ feedback messages for this particular DUC or discard messages for this 
particular DUC. 

If the RR poll bit is set to 1, the following priority rules shall apply for the first SCH granted: 

1) if a discard message is available, this message shall be sent with highest priority; 

2) if no discard message is to be sent, an RR message for this particular DUC shall be sent. 

For acknowledged mode, the remaining granted SCHs shall be used for ARQ feedback messages for this particular 
DUC. 

For unacknowledged mode, the remaining granted SCHs shall be filled with dummy SCHs. 

If the RR poll bit is set to 0, the following rules shall apply: 

1) For acknowledged mode, all granted SCH shall be used for ARQ feedback messages for this particular DUC. 

2) For unacknowledged mode, all granted SCH shall be filled with dummy SCH. 

Following rules shall apply to MTs to access SCHs that are granted for the DCCH (DLCC ID = 0) in uplink direction: 

1) RLC messages shall be sent with highest priority if available. 

2) If SCHs are left and resources for the DCCH are to be requested, a RR for the DCCH shall be sent with 
second priority. 

If SCHs are left, RRs for other DUCs shall be sent, including RRs for direct link. 

NOTE 1 : The RR poll bit is not used for the DCCH (DLCC ID = 0). 

NOTE 2: A result of rule 3 may be that the same RR is sent twice in a frame. This occurs if the AP/CC happens to 
poll for a RR for the same DLCC that the MT decided to send in the SCH granted for DCCH. 

The rules above make sure that it is mostly the AP/CC that determines whether a RR for a DUC shall be created by an 
MT. If the AP/CC does not poll for an RR, the RCH shall be used if necessary. The use of SCHs for the DCCH to 
transmit RRs for other DUCs may help to decrease the load on the RCH. 

Polling of RRs for the DiL is not possible. RCH and SCHs for the uplink DCCH shall be used to transmit RRs for direct 
hnk DUCs. To reduce the load on the RCH in DM, the AP/CC should schedule uphnk SCHs with DLCC ID = (i.e. 
uplink DCCHs). 

The downlink SCHs granted for a particular DLCC ID > (i.e. not the DCCH) shall not be used for messages other than 
ARQ feedback messages for this particular DUC or discard messages for this particular DUC. 

Downlink SCHs with DLCC ID=0 shall only be used for downlink RLC messages. 

The priority for the use of downlink SCHs granted for a particular DLCC ID is an internal AP/CC decision and is out of 
the scope of the present document. 



£75/ 



51 ETSI TS 101 761-1 VI. 1.1 (2000-04) 

The direct link SCHs granted for a particular DLCC ID > (i.e. not the DCCH and RBCH) shall not be used for 
messages other than ARQ feedback messages for this particular DUC or discard messages for this particular DUC (same 
as for downlink SCHs). No RR poll bit is available in the RG for the direct link. 

The following priority rules apply for the first SCH that is granted for a DUC with a DLCC ID>0 in the direct link: 

1) If a discard message is available, this message shall be sent with highest priority. 

2) If no discard message is available, an ARQ feedback message for this particular DUC shall be sent in case of 
acknowledged mode. For unacknowledged mode, a dummy SCH shall be sent. 

3) All other SCHs shall be used for ARQ feedback messages for this particular DUC in the case of acknowledged 
mode. For unacknowledged mode, dummy SCHs shall be sent. 

Direct hnk SCHs with DLCC ID=0 shall only be used for RLC messages. 

6.3.2.5 RCH 

At least one RCH shall be allocated per sector in each MAC frame. 

The RCHs for all sectors shall be clustered together, i.e. the RCH phases for different sectors shall follow directly 
each other. 

The RCH shall use BPSK with coding rate 1/2. 

Between RCHs shall be space for preamble and guard time, see subclause 6.9. 

A terminal shall use not more than one RCH per MAC frame. 

Recommendation: A RR for a particular DLCC should be transmitted in an RCH only if the buffer status has 
changed significantly or after a minimum number of MAC frames. 

Recommendation: The transmission of RR messages in RCHs should be kept to a minimum. In particular, for active 
DUCs it is recommended to wait for the grant of an SCH for at least one MAC frame before accessing the RCH. 

6.3.2.6 Order of the transport channels 

• For a single sector in the AP/CC, the order of the transport channels from an MT's point of view shall be BCH - 
FCH - ACH - DL phase - (DiL phase) - UL phase - RCH. The DiL phase can only exist if both AP/CC and MT 
support it. All possible combinations of the MAC frame for an AP or CC using a single sector is depicted in 
figure 34. 
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Figure 34: All possible combinations of MAC frames for an AP using a single sector 

For an AP with n sectors, the sequence of channels shall be: BCHl, BCH2, ..., BCHn, FCHl, ACHl,. . .,FCH 
#k,ACH #n, DL #i,. . ., DL #k, UL #i,. . ., UL #k, RCHs #1, RCHs #2, RCHs #n. Several RCHs can be allocated for 
a particular sector. 

It is mandatory for MTs to support multiple sectors. It is optional for the AP. 

For the downlink, the SCH PDUs belonging to a particular DUC shall be transmitted in before the LCHs belonging 
to this connection. 

For the uplink, the LCH PDUs belonging to a particular DUC shall be transmitted before the SCHs belonging to 
this connection. 

For direct link, the LCH PDUs belonging to a particular DUC shall be transmitted before the SCHs belonging to 
this connection. 

All granted downlink LCHs and SCHs for a single MT shall be grouped together. 

All granted uplink LCHs and SCHs for a single MT shall be grouped together. 

All granted direct link LCHs and SCHs between a pair of MTs shall be grouped together. 

If an MT has been granted resources in the uplink or direct link for a specific DUC, it is not allowed to transmit 
data for a different DUC. 

If an AP/CC has been granted resources in the downlink or direct link for a specific DUC, it is not allowed to 
transmit data for a different DUC. 

All RGs in the FCCH belonging to one MAC ID in CM or belonging to the same pair of source and destination 
MAC IDs in DM, shall be grouped such that they result in a single PDU train. 

NOTE: The MAC ID may refer to MTs but also to the RBCH, UBCHs or UMCHs. Examples for the 
consequences of this rule are: 

all UBCHs originated from the same transmitter for a single CL are sent in one PDU train; 
RBCHs originated from the same transmitter are sent in one PDU train; 
each UMCH is sent in a separate PDU train. 
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6.3.2.7 Logical Channels 

The following rules apply for the use of logical channels: 

• Not more than one RG for the downlink RBCH shall be present per MAC frame per sector. Its existence in the 
MAC frame is indicated in the BCCH. 

• Not more than one RG for each downlink UBCH shall be present per MAC frame per sector per implemented 
convergence layer. 

• Not more than one RG shall be present for each downlink UMCH per MAC frame per sector. 

• Not more than one RG shall be present for each direct link UMCH per MAC frame per sector. 

• Not more than one RG shall be present for each direct link UBCH per MAC frame per sector per implemented 
convergence layer. 

• Not more than one RG shall be present for each direct link RBCH per MAC frame per sector. 

• Not more than one RG shall be present for the DCCH per MT per direction per MAC frame in CM. 

• Not more than one RG shall be present for the DCCH per MT pair per direction per MAC frame. 

• If resources for the DCCH are granted, they shall always be located at the end of a PDU train. 

6.3.2.8 Handling of resource request messages 

If a RR or discard message for a particular CM DUC has been sent in an SCH in the current MAC frame, additional RRs 
for this particular DUC shall not be sent in an RCH in this MAC frame. If a RR for a particular DM DUC has been sent 
in an SCH with DLCC ID = in the current MAC frame, additional RRs for this particular DUC shall not be sent in an 
RCH in the MAC frame. 

A new RR or discard message shall update the #LCH and #SCH fields of a previously sent RR or discard message. 

In centralized mode, the #SCH field in RRs for DLCC ID = is used to indicate the number of requested SCHs for the 
DCCH in the uplink. These RRs can be sent in an SCH of the uplink DCCH or in an RCH. In direct mode, the #SCH 
field in RRs for DLCC ID = is used to indicate the number of requested SCHs for the DCCH or RBCH in the direct 
link. These RRs can be sent in an SCH of the uplink DCCH or in an RCH. 

In centralized mode, the #SCH field in a RR or discard message for DLCC ID>0 shall always be set to zero if it is sent 
in an SCH. If the MT requests to send a discard message, an RR with the #SCH field set to one shall be sent in an RCH. 

For DiL DUCs, the #SCH field in an RR for DLCC ID>0 shall be set to one if the MT requests to send a discard 
message. Otherwise it shall be set to zero. The RR for a DiL DUC with the #SCH field set to one can be sent in an RCH 
or an uplink SCH for DLCC ID = (uplink DCCH). 

The #LCH field in the RR or discard message that is to be sent in a certain MAC frame shall be equal to or less than the 
number of LCHs that are waiting for transmission in the respective transmission buffer. The MT is not allowed to 
request resources for LCHs that were first sent in the last rtt frames (including the current frame), see subclause 6.3.5. 
This means, the RR or discard message shall not contain LCHs that have been sent the first time less than one rtt ago. 

NOTE: This rule does not apply to LCHs that have already been retransmitted. In the case of flow control, the MT 
is only allowed to request a number of LCHs up to the flow control limit, see subclause 6.4.2.14. 

The value of the #LCH field in an RR or discard message shall have been calculated not more than one MAC frame ago. 
Newly arriving PDUs should be taken into account at the latest in the MAC frame after their arrival. The granted volume 
in a frame shall be taken into account in RRs or discard messages. 

EXAMPLE: If the MT has 100 new LCHs for a DUC waiting for transmission and the granted volume is 10 
LCHs, then the #LCH field shall not exceed 90. 

The LCHs that are discarded in a MAC frame by sending a discard message shall not be included in the #LCH field of 
the corresponding discard message or of an RR that is sent in the same MAC frame. 
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The retry bit shall be set per MT and its status shall be sent in all RRs. Upon a not successful RCH access attempt 
indicated by the RFCH, the retry bit status for the MT shall be set to 1 . The status of the retry bit is kept until any RR 
has been delivered succesfuUy, irrespective over which tranport channel the RR is sent. The retry bit status shall be set 
to after successful delivery of any RR message. If the RR has been sent in an SCH, it shall be assumed as successfully 
received. If the RR has been sent in an RCH, it shall be assumed as successfully received if the RFCH indicates a 
successful transmission. 

The ARB bit shall be used as follows: 

1) If the transmitter has unacknowledged (transmitted and waiting for feedback) LCHs or new (not yet transmitted) 
LCHs to be transmitted or negatively acknowledged LCHs, the transmitter shall set the ARB= 1 . 

2) If the transmitter has neither unacknowledged nor new nor negatively acknowledged LCHs, the transmitter shall set 
ARB=0. An exception to the rule is given below. 

Applying the above rules, the following three combinations of the number of the LCHs (#LCH) and ARB are 
considered. 

• #LCH=0 and ARB=0: The transmitter has neither unacknowledged LCH nor new nor negatively acknowledged 
LCHs to be transmitted (i.e. the buffer is empty). 

• #LCH>0 and ARB=1: The transmitter has unacknowledged LCH(s) or new LCH(s) or negatively acknowledged 
LCHs or any combination of the three to be transmitted. 

• #LCH=0 and ARB=1: Within the transmitters window or flow control (PC) limitation, neither unacknowledged nor 
negatively acknowledged LCHs nor new LCHs are to be transmitted but the transmitter buffer is not empty (e.g. 
stalled or flow control activated). 

NOTE: The combination #LCH>0 and ARB=0 is not allowed because ARB=0 indicates that the transmitter buffer 
is completely empty. 

6.3.3 Accessing the RCH 

The access to RCHs shall be controlled by a contention window CW^ maintained by each MT. The contention window 
shall be derived from the number a, where a is the number of retransmission attempts made by the MT. For the first 
access attempt, a shall be set to 0. The size of the contention window, CW^,is defined as follows, where n is the number 
of RCHs in the MAC frame where r^ is calculated: 

1 ) Initial Attempt: a=0, C Wq = n 



2) Retransmission: a>\, CW 



256 2" > 256 

2" n < 2" < 256 
n n>2" 



The RCH used for the a^^ retransmission attempt including an initial transmission (fl=0) shall be chosen by a uniformly 
distributed random integer value r^ within the interval [1, CW^]. The random number generator is not specified. MT 
shall start counting r^ from the first RCH in the MAC frame, in which the ACH indicates the failure of the previous 
access attempt. In case of a equal to 0, the MT starts counting with the first RCH in the current frame. This first RCH is 
specified by number 'rQ=l'. The RCH with number equal to r^ is the RCH that the MT shall access. The MT shall not 
access the RCH before its counter has reached the RCH with the number equal to r^. After receiving the ACH with a 
positive feedback, a shall be reset to 0. 

NOTE: The number n of RCH slots may vary from frame to frame. 

EXAMPLE 1 : Figure 35 shows an example for the third retransmission access attempt. After ACH announces 
failure of the previous retransmission access attempt a=2, MT determines CW^ from max(2^, n). 
Then the MT determines a random number r^ within the interval [1, CW^], where r^ is assumed to 
be 4 in the example. Figure 35 indicates that RCH4 is located in the same MAC frame. 
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Figure 35: An example of the next access RCH f#g+-\ within the current IVIAC frame 

EXAMPLE 2; Figure 36 shows the situation where the third retransmission access RCH r^ is located in the 

subsequent MAC frame. In this example, the frame i+1 has two RCHs=m that are announced by the 
BCH and the negative feedback for the previous retransmission a=2 is received in the ACH. The 
current CW^ is chosen from max (2^, n=2). r^ is assumed to be 4 and the MT starts counting r^ 
starting with the first RCH of the current MAC frame, i.e. the frame where the negative feedback 
has been received. Consequently, the MT is supposed to access the fourth of the following RCHs, 
irrespective of whether it is in the current or a subsequent MAC frame. In case of sector antenna, 
the MT shall count the RCHs within its own sector. 
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Figure 36: An example of the next access RCH r^g^^ located in the subsequent lUIAC frame 

6.3.4 Fixed capacity agreement (optional) 



6.3.4.1 



General 



The AP/CC and MTs may negotiate that the AP shall schedule a certain number of LCH and SCH in a certain number of 
frames. This negotiation is done during the DUC setup or a DUC modify, see TS 101 761-2 [5]. The negotiated fixed 
capacity shall be valid either until the DUC parameters are modified or until it is released. Additional resources may be 
requested using RRs as specified in subclause 6.2. 

If fixed capacity allocation has been negotiated for a DUC, see TS 101 761-2 [5], AP/CC and MT shall perform 
additionally the operations in the following subclauses 6.3.4.2 and 6.3.4.3. 

6.3.4.2 AP/CC Operation 

The AP/CC operation shall be the following: 

• After DUC setup or DUC modify the AP/CC shall wait for one Resource Request before granting resources in the 
case of an UL or DiL cormection. With this Resource Request the MT signals to the AP/CC that it is ready to start 
the fixed capacity allocation. The requested resources in this RR may be zero. For a DL connection, the AP/CC may 
start the fixed capacity allocation whenever it decides. If an MT using a fixed capacity agreement is absent for any 
RLC reason, see TS 101 761-2 [5], e.g. MT Absence or MT DFS Measurement, the AP/CC shall stop granting the 
fixed capacity for the time the MT is absent. After the MT has returned from absence, e.g. MT Absence or MT DFS 
Measurement, the AP/CC can only start granting the fixed capacity agreement according to the above rules for UL, 
DiL and DL connections. 
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• The AP/CC shall stop granting the fixed capacity for the time it is absent for any RLC reason, see TS 101 761-2 [5], 
e.g. AP Absence. After the AP/CC has returned from absence, e.g. AP Absence, the AP/CC shall start granting the 
fixed capacity agreement again. 

• The AP/CC shall grant the number of SCHs and LCHs per a certain number of MAC Frames as negotiated in the 
fixed capacity agreement. The periodicity of SCH and LCH is aligned to each other, i.e. both shall be granted in the 
same MAC Frame. 



EXAMPLE: 



If #LCH=4 for every second MAC Frame and #SCH=1 for every forth MAC Frame, the granted 
resources according to polling are the as shown in table 28. 

Table 28: Example for Fixed Capacity Agreement: 



MAC Frame Number 


Granted 
Resources 


1 


- 


2 


4 LCH 


3 


- 


4 


4 LCH, 1 SCH 



The maximum number of SCHs which can be negotiated in the fixed capacity agreement is one, see TS 101 761-2 [5]. 

• The number of SCHs, as negotiated in the fixed capacity agreement, shall be used for RRs only. 

• If an SCH is granted for an uplink DUC according to the fixed capacity agreement, the AP shall set the RR poll bit 
in the RG IE. If additional SCHs are granted according to the basic procedure, the RR poll bit shall be set according 
to the AP's choice. 

• If an SCH is granted according to the fixed capacity agreement for a DiL connection, this SCH shall be granted for 
the uplink DCCH (DLCC ID=0) instead of the DiL LCCH.. 

• If the MT requests resources by using RRs for a connection using the fixed capacity agreement, the AP/CC shall 
consider the requested resources in addition to the resources negotiated in the fixed capacity agreement. 

NOTE 1 : The AP/CC does not need to take into account that LCHs may have been queued during MT absence. The 
transmitter of LCHs is responsible for doing so (MT for UL and DiL, AP for DL). 

NOTE 2: Power saving is not allowed for MTs using a fixed capacity agreement, see TS 101 761-2 [5]. 

NOTE 3: The AP/CC is allowed to allocate more SCHs than what has been agreed during the negotiation. 

If the AP/CC can not grant the number of SCHs and LCHs as negotiated in the fixed capacity agreement, the AP/CC 
shall use the appropriate RLC procedures to modify the negotiated resource allocation or to release the connection, see 
TS 101 761-2 [5]. 

NOTE 4: The above situation could for example occur when the MT requests for a more robust PHY mode in a 
Resource Request. 

6.3.4.3 MT Operation 

The MT operation is the following: 

• After DUC setup, the MT shall transmit one Resource Request in order to start using the fixed capacity agreement 
in the case of an UL or DiL connection. The content of the RR is according to the rules for composing a RR. 

• If the MT is not granted the number of SCH and LCH as negotiated in the fixed capacity agreement, the MT may 
use Resource Requests to request for the resources not granted by the fixed capacity agreement in the case of an UL 
or DiL connection. 
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• The MT may use Resource Requests for requesting resources required additionally to the fixed capacity agreement. 

• A Resource Request with the #SCH and #LCH fields set to shall be used to change the PHY mode of a connection 
with fixed capacity assignment without requesting additional resources. 

• If the MT is polled for a Resource Request with the RR poll bit set to 1 in CM, the MT shall transmit a Resource 
Request or Discard Message. 



6.3.5 Timing requirements 



6.3.5.1 



Reference point and start pointers 



The basic time unit of the MAC frame shall be called slot and shall have a duration of 400 ns. The position of the 
transmission of transport channels and PDU trains in the MAC frame shall be identified by either a 12 or 13 bit pointers 
given in the FCCH and BCCH. The smallest addressable granularity of these pointers is a slot of 400 ns. The duration of 
each MAC frame shall be 2 ms. 

The following rules apply to the timing between APs/CCs and MTs: 

• The reference point of an MT for all start pointers shall be the first sample of the first BCH preamble of a MAC 
frame. This means that the first sample of the first BCH preamble shall be addressed with a value of in the start 
pointer. In the case where multiple sectors are used, the MTs shall also use the first sample of the preamble of the 
first BCH as the reference point. This is illustrated in figure 37. 



Preamble 


BCH#1 
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1 1 1 1 

"4- 





400 ns 



Reference point 

Figure 37: Definition of the reference point 

• When calculating the pointers in the BCCH and the FCCH, the AP's scheduler shall take the PHY layer preambles 
and the needed guard spaces into account, see subclause 6.9.2. The MT has to take the preambles implicitly into 
account when evaluating the pointers. This is explained for the up- and downlink by the arrows in the examples in 
figure 38 and for the direct link in figure 39. For the random access phase the MTs have to take into account the 
RCH guard space which is broadcast in the BCCH, see TS 101 475 [4], and implicitly the preamble as depicted in 
figure 40. 
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Figure 38: Example for pointers for the up- and downlink 
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Direct Link 
Case 1: same TX, 
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Figure 40: Examples for pointers for RCHs for different sectors 



Minimum is Radio 
turn around time 



The selection of the duration of the guard time between uphnk transmissions and direct link transmissions of 
different MTs shall be performed by the AP/CC. 

In direct link, guard spaces are only required if the transmitter of the next PDU train is different from the transmitter 
of the previous PDU train. 

Each PDU train transmitted by MTs shall be preceded by only one PHY preamble in CM and DM. 

NOTE: The PHY layer is responsible to insert and remove the preambles. It is assumed that some control 
information about the insertion is passed down from the MAC to the physical layer. 



6.3.5.2 



Minimum time between ACH and UL phase 



The default value for the gap between the end of the ACH announced for a particular sector and the first uplink 
transmission of each individual MT which receives a RG for this particular sector shall be 1024 )is. MTs can optionally 
request a different value during association, see TS 101 761-2 [5]. The handling of the gap is illustrated in figure 41. 

If an MT requests a longer gap than the default value, the AP/CC shall support this. If the MT requests a shorter gap 
than the default gap, the AP/CC may support this. The gap is due to a processing delay and is based on the processing 
categories given in table 29. 
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Figure 41 : Example for the gap between the ACH and the uplink 



Table 29: Processing category 



Processing category 
MSB - LSB 


Gap between the end of ACH and the 
beginning of the UL transmission [|j.s] 


Gap in OFDIUI symbols 

(assuming 4 |j.s duration 

per OFDIUI symbol) 


000 








001 


16 


4 


010 


32 


8 


oil 


64 


16 


100 


128 


32 


101 


256 


64 


110 


512 


128 


111 


1024 


256 



Before the processing delay is negotiated, the AP/CC shall schedule the MT according to the default class 111, i.e. a 
processing delay of 1024 |is shall be assumed. 



6.3.5.3 



Minimum time between ACH and DiL phase 



If a DiL phase exists before the uplink phase, the minimum time values listed in subclause 6.3.5.2 shall apply to the gap 
between the end of the ACH and the beginning of the DiL transmission of the first DiL terminal which is not the AP or 
CC. 



6.3.5.4 



Request - Grant delay 



There is no explicit minimum or maximum delay of resource granting. If an MT does not get any grant it may send the 
resource request again. More detailed rules about the use of RR messages are given in subclause 6.3.2.8. 



6.3.5.5 



ARQ delays 



Both the AP/CC and the MT announce their ARQ processing delay in number of MAC frames for both the transmit and 
receive direction during association time (see TS 101 761-2 [5]). The extra ARQ processing delay in transmit direction 
(denoted by d^^^^ ^y, and d^^^ ^j) means the minimum number of frames before the transmitter can transmit LCHs based on 
the processing of an ARQ feedback message after its reception. The extra ARQ processing delay in receive direction 
(denoted by dj.^^ j^ and dj.^^ j^j) means the minimum number of frames the receiver has to wait before it can produce an 
ARQ feedback message for received LCHs. The round-trip times (rtt) in the uplink and downlink directions are then 
given in numbers of MAC frames by 

rttuplink = 'ltx,MT + 'Irx.AP+l 



rtt 



downlink ~ '^rx.MT + ^^tx.AP+l 



The scheduler in the AP/CC shall take the values dj.^ j^^, and dj.^^^ jyjj defined in table 1 into account and should grant 
SCHs for ARQ feedback messages only when the receiver is ready to send them. For ARQ delay class 0, it should not be 
allowed to grant reception and transmission within a shorter interval of 40 )is. 

For direct link communication, the AP/CC knows the ARQ processing delay for both terminals of a DiL connection after 
their association. The round-trip times for the send and receive directions of a DiL connections are given in numbers of 
frames by 

'"forward = '^tx.MTl + 'lrx,MT2+l 
rttbackward = 'Jfx.MTl + ^^tx.MTl+l 
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The scheduler in the AP/CC shall take dj.^ ]y[j2 and dj.^ jyjjj defined in table 30 into account and should grant SCHs for 
ARQ feedback messages only when the receiver is ready to send them. For ARQ delay class 0, it should not be allowed 
to grant reception and transmission within a shorter interval of 40 )is. 

Table 30: ARQ delay class 



Delay class 


MSB-LSB 


dj-^ , d^^ value for rtt calculation (i.e. # frames) 


Required maximum processing 
delay 





00 





40 us 


1 


01 


1 


2 ms 


2 


10 


2 


4 ms 


3 


11 


3 


6 ms 



6.3.6 Handling extra capacity allocated to MTs in uplink or direct link 
direction 

An MT need not use all granted resources for uplink and/or direct link traffic. The MT shall not leave any gaps in a 
PDU train. 

If a transmitter is in unacknowledged mode and has no data for an LCH available, it shall send the dummy LCH (see 
subclause 6.4). In acknowledged and repetition mode, the transmitter may repeat the respective LCH. The content of the 
dummy LCH payload field is not specified. 

6.3.7 Error indication bits 



6.3.7.1 



General 



The error indication bits shall be included into uplink Resource Requests and Discarding PDUs. The first two of the 
error indication bits, starting with the MSB, shall be called the error reason Bits. They shall contain a summary of the 
error reasons of either the BCHs and FCHs or LCHs, calculated over a number of MAC frames. The LSB shall contain 
an indication of the overall channel quality and is called the channel quality bit. The mapping of the error indication bits 
is presented in figure 42. Table 3 1 introduces the semantics of the error reason bits, table 32 of the channel quality bit. 
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b3 b2 b1 




Reason Bits 



Channel 
Quality Bit 



Figure 42: Bit representation of the Error indication bits 
Table 31 : Error reason bits 



. Bits 


Meaning 


00 


OK/Not enough measurements 


01 


Fading 


10 


Interference 


11 


Receiver Compression 
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Table 32: Control Channel Quality bit 



Bits 


Meaning 





OK 


1 


Not OK 



The error reason bits shall be calculated by each MT separately for each connection that uses resource requests. Thus for 
e.g. broadcast and multicast connections the bits are not calculated. 

6.3.7.2 Generation of the Error Indication Bits 

For the purpose of describing the actions of the MT, some informative variables are introduced. They are used as an 
intermediate storage and are evaluated in one step to derive the error indication bits: 

• Frame-error-reason: it describes the error reason in a MAC frame for a connection. The frame error reasons are 
finally evaluated to derive the error reason bits. 

• Frame-channel-quality bits: it indicates the occurrence of an error in a MAC frame for a BCH or FCH. The frame 
channel quality bits are finally evaluated to derive the control channel quality bit. 

• Latest-frame-channel-error: an element that describes the latest error reason for the control channels (BCH and 
FCH). 

A reference RSS level shall be obtained from the preamble of the BCH of the current frame. If the CRC of a BCH, FCH 
or LCH fails, the reference RSS level shall be compared to an RSS threshold value (see TS 101 475 [4] on receiver 
sensitivity) that corresponds to the used PHY mode. The reason for failure shall then be one of the following: 

1 . 1 Fading (F), if the reference RSS level was lower than the threshold, 

1 .2 Interference (I), if the reference RSS level is higher than the threshold but lower than L dBm, 

1 .3 Receiver Compression (RC), if the reference RSS level is higher than L dBm (caused by the receiver being 
too close to the transmitter). 

L is -25 for device class 1 terminals and -35 for device class 2 terminals (see TS 101 475 [4]). 

If the CRC evaluations are successful, the BCH, FCH or LCH shall be considered successful (OK). 

If the RSS measurement of the BCH has not been successful, the frame-error-reason and the latest-frame-channel-error 
shall be set to F for all connections. If the RSS measurement of the BCH has been successful and any CRC check in the 
BCH or FCH has failed, then the following rules shall be applied: 

2.1 The frame-error-reason for this frame shall be set either to F, RC or I for all connections according to the 
rules to calculate the reason for failure given above. In the calculation, the sensitivity threshold for BPSK 
with code rate Vi shall be used. 

2.2 The frame-channel-quality bit for this frame shall be set to NOT OK. 

2.3 The frame-error-reason according to 2.1 is stored in the latest-frame-channel-error. 

If the RSS measurement of the BCH has been successful and no CRC in BCH or FCH has failed, then: 

3.1 If no DL traffic has been allocated for the MT in the current frame, the frame-error-reason bit shall be set to 
OK for all connections. 

3.2 If DL traffic has been allocated for the MT, it shall update the frame-error-reason and frame -channel-quality 
according to 3.3, 3.4 and 3.5 for the particular connections that have been granted resources. For all other 
connections shall the frame-error-reason bit be set to OK. 

3.3 If no CRC of any LCH has failed, the frame -error-reason shall be set to OK. 

3.4 If one or more CRC of LCHs has failed, the MT shall set the frame -error-reason (F, I or RC) for this 
connection, depending on the reference RSS value. 
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3.5 The frame-channel-quality for this frame shall be set to OK. 

NOTE: In the first version of the DLC TS basic transport function both the BCH and FCH will use the same PHY 
mode. In future phases, the PHY modes may be different. 

The frame-error-reasons of the last 50 frames shall be stored. The frame-error-reason shall be cleared after handover, 
frequency change or if the mobile is absent intentionally for more than 10 frames (e.g. making measurements or due to 
sleep mode). In case of lost MAC frames, the frame error reason shall be set to (F), i.e. the rule given above for the loss 
of the RSS measurements applies. 

When a PDU containing error indication bits is to be transmitted, the MT shall perform the following actions: 

4.1 The Control Channel Quality bit shall be set to 1 if any frame-channel-qualities has been set to NOT OK in 
the last 20 frames. Otherwise Control Channel Quality shall be set to 0. 

4.2 If the Control Channel Quality bit is set to 1, the error reason bits shall be set according to the latest-frame- 
channel-error field (F, I or RC). 

4.3 If the Control channel quality bit is set to zero the error reason Bits shall be set according to 4.4. 

4.4 The Frame-error-reasons belonging to the connection shall be evaluated. If there has been no errors in the last 
50 frames or there are less than 50 frame -error-reasons available, OK/not enough measurements (00) shall be 
set for the PDU. Otherwise, the error reason that occurred most often shall be transmitted in the PDU, i.e. 01 
for fading, 10 for interference or 1 1 for receiver compression. If there is an equal number of faded and 
interfered frames, anyone of these two can be selected. As an MT transmits the Error Indication Bits, it shall 
make sure that they have been produced not later than at the end of the previous MAC frame. 

6.3.7.3 Direct Mode 

The two Error Reason bits of the Error Indication bits shall be included into Resource Request messages for the direct 
link. The Error Reason Bits shall always describe the error reason for the control channel, namely BCH and FCH. Each 
MT that uses direct link resource requests shall calculate the error reason bits, and include them in all its RR PDUs for 
direct link unicast, multicast or broadcast, independent of the coimection. 

6.3.7.3.1 Generation of the Error Indication Bits in DM 

A reference RSS level shall be obtained as in CM. If the CRC of a BCH or FCH fails, the reference RSS level shall be 
compared to an RSS threshold value (see TS 101 475 [4] on receiver sensitivity) that corresponds to the used PHY 
mode. The reason for failure shall then be as in CM. 

If the RSS measurement of the BCH has not been successful, the latest-frame -channel-error shall be set to F. If the RSS 
measurement of the BCH has been successful and any CRC check in the BCH or FCH has failed, then the following 
rules shall be applied: 

1.1 The latest-frame-error-reason shall be set either to F, RC or I according to the rules given in 6.3.7.2. 

1 .2 The frame-channel-quality bit for this frame shall be set to NOT OK. 

If the RSS measurement of the BCH has been successful and no CRC in BCH or FCH has failed, 

2.1 The frame-channel-quality for this frame shall be set to OK. 

NOTE: In the first version of the DLC TS basic transport function both the BCH and FCH will use the same PHY 
mode. In future phases, the PHY modes may be different. 

All the frame -channel-qualities shall be set to OK after handover, frequency change or if the mobile is absent 
intentionally for more than 10 frames (e.g. making measurements or due to sleep mode). In case of lost MAC frames, the 
latest-frame-error-reason shall be set to (F), i.e. the rule given above for the loss of the RSS measurements applies. 

When a PDU containing error indication bits is to be transmitted, the MT in direct mode shall perform the following 
actions: 

3.1 If any frame-channel-qualities have been set to NOT OK in the last 20 frames, the error reason bits shall be 
set according to the latest-frame-channel-error field (F, I or RC). 
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3.2 Otherwise the error reason bits shall be set to indicate OK (00). 

NOTE: The Control Charmel Quality bit is not available in Resource Request for DiL. 



6.4 



Error Control 



6.4.1 General 

The AP/CC and MT shall support three error control modes: 

1) Acknowledged mode: Provides with reliable transmissions using retransmissions to improve the link quality. The 
retransmissions are based on acknowledgements from the receiver. Low latency can be provided by a discard 
mechanism. 

2) Repetition mode: Provides a reliable transmission by repeating the LCHs. 

3) Unacknowledged mode: Provides an unreliable, low latency transmission. 

UDCHs for a certain connection shall either be sent in acknowledged or unacknowledged mode. The negotiation during 
connection set up is defined in TS 101 761-2 [5]. In the case of the acknowledged mode, an implicit bi-directional 
LCCH is set up (without RLC signalling). 

UMCH, DCCH on LCH and RBCH on LCH shall use the unacknowledged mode. 

UBCHs shall either be sent in repetition or unacknowledged mode. In the case where multiple convergence layers are 
supported, the UBCHs may use different error control modes. In the case of the repetition mode, an implicit 
unidirectional LCCH is set up corresponding to a UBCH. 

The figures below illustrate the possible setups. In these examples, the terms "transmitter" and "receiver" mean that the 
data transmission under consideration is from the transmitter to the receiver, although e.g. a connection using the UDCH 
is in general bi-directional. The RR message control flow is not considered. 

Figure 43 illustrates the situation in the case of the acknowledged mode. A corresponding LCCH is available which is 
used for ARQ feedback messages from the receiver to the transmitter and for discard messages from the transmitter to 
the receiver. 
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Figure 43: Illustration of the data and control flow in acknowledged mode 

Figure 44 illustrates the situation in the case of the unacknowledged mode. The data flows only from the transmitter to 
the receiver, no control data flow for ARQ feedback or discard messages is allowed. 
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Figure 44: Illustration of the data and control flow in unacknowledged mode 

Figure 45 illustrates the situation in the case of the repetition mode. In this case, an implicit unidirectional LCCH for 
discard messages from the transmitter to the receiver is available. 




Figure 45: Illustration of the data and control flow in repetition mode 



6.4.2 Acknowledged mode 



6.4.2.1 General 

The EC functions using acknowledge mode can be applied to DLC user connections. 
The error control function is responsible for: 

• Evaluation and generation of the CRC for LCHs. 

• Detection of missing LCHs, i.e. LCHs that have not been received yet or detected by the CRC function as 
erroneous. 

• Handling of LCHs: Where applicable, performing retransmission of missing LCHs (ARQ function), in order 
delivery of LCHs to the CL. 

• Generation and analysis of ARQ feedback messages. 

• Generation of discard messages and act accordingly. 

NOTE 1 : The scheduler is responsible for the allocation of resources for ARQ feedback messages. 

NOTE 2: The term "positively acknowledged" means that an LCH has been correctly received and this is reported 
to the transmitter. The term "negatively acknowledged" means that an LCH has not been correctly 
received and this is reported to the transmitter. 

The support of the acknowledged mode for UDCHs is mandatory for MT and optional for AP/CC. 
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6.4.2.2 Notations 

LCHs are identified by a sequence number of length 10 bits which is interpreted modulo 2^^. The relation [A < B] mod 
21*^ holds, if B is in the set [A+1, A+2, ..., A+29-1] mod 21°. 

A set of sequence numbers [A, B] mod 2^^ is the set of sequence numbers [A, A+1, ..., B] mod 2^^. 

A set of sequence numbers [A, B) mod 2^^ is the set of sequence numbers [A, A+1, . . ., B-1] mod 2^^. 

Furthermore, X^, denotes an LCH sequence number, X^ denotes the bitmap block number that contains the LCH of 
sequence number X^,, and X^^ denotes the first sequence number in block X^,. 

NOTE 1 : X^ may be obtained by truncating the 3 LSBs of Xj,. 

NOTE 2: X^^ may be obtained by concatenating [000] after the LSB of X^,. 

The terms higher and lower sequence numbers are interpreted within a window (i.e. interval of at most 512 LCHs) of 
sequence numbers. 

6.4.2.3 LCH Sequence Number SN 

Each LCH shall be assigned a 10-bit sequence number. Sequence numbers shall be incremented by 1 for subsequent 
LCHs and calculated modulo 2^^. 

NOTE: The sequence number is generated and evaluated by the EC function. 

6.4.2.4 Window Sizes ks 

The window size k^ is negotiated at connection set up, see TS 101 761-2 [5]. Possible window sizes are; 32, 64, 128, 
256,512. 

NOTE: The maximum window size is half the size of the sequence number space to prevent ambiguities in the 
interpretation of sequence numbers. 

6.4.2.5 Receiver window 

The receiver window is the interval of sequence numbers that are eligible for reception. The bottom of the receiver 
window RxBoWj, is the lowest sequence number not yet received correctly by the receiver. 

The receiver shall maintain RxBoW^ as a full 10 bit sequence number since RxBoW^ may not be aligned on bitmap 
blocks boundaries. 

The receiver window is the set of sequence numbers [RxBoW^ RxBoW(,j, + k^). 

6.4.2.6 Transmitter window 

The transmitter window is the interval of sequence numbers that are eligible for transmission. The bottom of the 
transmitter window TxBoW^, is the lowest sequence number that has not yet been positively acknowledged by the 
receiver. 

The transmitter window is the set of sequence numbers [TxBoWj,, TxBoWj,j, + k^). 

TxBoWj, shall be updated to the lowest negatively acknowledged LCH within BMB 1 when the transmitter receives an 
ARQ feedback message with the CAI bit set. 
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6.4.2.7 



Bitmap Blocks (BMB) and Bitmaps Block Numbers (BMN) 



The ARQ feedback messages sent by the receiver shall contain Bitmap Blocks. The sequence number space, starting 
from sequence number 0, is partitioned into consecutive intervals of sequence numbers. A bitmap block is mapped to an 
interval of sequence numbers in the following way. A bit having a given position in the bitmap block is associated to the 
sequence number having the same position in the sequence number interval, e.g. the most significant bit of a bitmap 
block is the lowest sequence number of the interval. A bit set to 1 in the bitmap block positively acknowledges the LCH 
with the sequence number associated to the bit. A bit set to in the bitmap block signals the negative acknowledgement 
of the corresponding LCH. 

The sequence number intervals are of size 8, and therefore Bitmap Blocks shall be of length 8 bits. The address, or 
Bitmap Block Number BMN(,, of a bitmap block is the position of the sequence number interval it covers. A bitmap 
block in the ARQ control message can be addressed either by an absolute or a relative address. An absolute address is 7 
bits long. A relative address is 5 bits long. The address of BMB2 that is relative to BMB 1 is the absolute address of 
BMB2 minus the absolute address of BMB 1. In addition, the address of BMB3 relatively to BMB2 is the absolute 
address of BMN3 minus the absolute address of BMN2. 

NOTE 1 : The absolute address is the common first 7 bits of the sequence numbers covered by the bitmap block. 

Bitmap blocks shall appear in increasing order in the ARQ control message. 

NOTE 2: Details about the handling of processing delays can be found in subclause 6.3.5. 

NOTE 3: An ARQ feedback message contains information concerning only a fraction of the receivers' window. 

Those LCHs whose sequence numbers are not covered, e.g. LCHs between BMNl and BMN2, can not be 
considered as positive acknowledged based on only this ARQ feedback message. 

NOTE 4: A 7 bit long absolute address can address any bitmap blocks. A 5 bit long relative address might in some 
cases limit the set of bitmap blocks that can be addressed. 

An example for the ARQ feedback handling is depicted in figure 46. 



SN=512 
Block 64 



BMB3 




MSB 



10011111 



SN=768 

Block 96 



-^=256 

Bloct!r32 



MSB 



1111110 1 



SN=128 

Block 16 



Block 127 



SN = 

Block 



Figure 46: Example for the ARQ feedback handling 
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The example describes the bitmap coding in the case of reception errors of the LCHs with sequence numbers <270>, 
<329>, <330>. It is assumed that the receiver has received the LCHs with sequence numbers of up to <571> before 
transmitting the ARQ feedback message. The numbers given in the example have the following meaning: 

BMNl = 33 represents the absolute coding of the block number 33 that comprises sequence numbers <264> to 
<271>. 

BMB 1 = [11111101] indicates the LCH with sequence number <270> as erroneous. 

BMN2 = 8 refers to block number 41, which covers sequence numbers <328> to <335>. It is relative to the block 
number indicated in BMNl, which is 33 in this example. 

BMB2 = [1001 1 111] indicates reception errors of LCH with sequence numbers <329> and <330>. 

BMN3 = 30 refers to block number 71 (sequence numbers <568> to <575>). It is relative to BMN2. It indicates 
the highest correctly received LCH with the sequence number <571>. 

BMB3 = [11 1 10000] indicates the correct reception of the LCHs with sequence numbers <568> to <571>. 

Upon reception of the ARQ feedback message, the transmitter can release previously transmitted packets with sequence 
numbers up to and including sequence number <269> if the CAI bit is set, and the logical check of the ARQ feedback 
message was successful (see subclause 6.4.2.10). 

In this case, the transmit window (TxBoWj.) is advanced to <270>. 

The receiver window (RxBoW^,) is set to <270>. 

6.4.2.8 Cumulative Acknowledgement (CumAck) 

The receiver may positively acknowledge all LCHs with sequence numbers up to a certain value, CumAckj,, by setting 
the CAI bit in the ARQ feedback message. The BMB 1 shall contain at least one negatively acknowledged LCH. The 
transmitter sets its bottom of window, TxBoWj,, to the lowest negatively acknowledged LCH within BMB 1 .The LCHs 
below but excluding TxBoWj, are regarded as cumulatively positively acknowledged by the receiver. 

If the receiver has not generated an ARQ feedback message with the CAI bit set in the last rtt including the current 
frame, then it shall generate a cumulative acknowledgement (set the CAI bit) in at least one ARQ feedback message the 
next time ARQ feedback messages are transmitted. An exception of this rule is defined when the receiver is in flow 
control, see subclause 6.4.2.14. 

At the receiver side, the CumAckj, sequence number shall be the bottom of the receive window, RxBoW^. 

6.4.2.9 EC Reset of the connection 

The EC reset procedures set both transmitter and receiver in a well-defined state from which communication can start or 
restart. The support of the Reset procedure is mandatory. Each side of a connection shall be able to initiate a Reset. The 
peer entity shall accept the Reset request and shall acknowledge it. The message exchange for the EC connection reset is 
defined in TS 101 761-2 [5]. 

The EC connection reset message exchange in the RLC shall be triggered to exit abnormal states of the EC protocol. 
The reset procedure that shall be performed in the EC entity shall include the following actions; 

The receiver shall discard all data in its reception buffer; 

The transmitter may discard data in its transmission buffer; 

The bottom of windows are set to 0; 

If the connection is flow controlled, exit the flow control state; 

Clear all other ARQ state information (such as acknowledgement bitmaps, rtt considerations etc.). 
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Regardless of the EC connection reset procedure, the reset actions given above shall be performed for single or all 
connections with acknowledged mode in certain situations that are originated in the RLC, see TS 101 761-2 [5]. 
Examples are: 

association; 

- re-Association; 
connection Setup; 
connection modify; 
handover to a new AP; 

connection reset requested by the peer entity. 

6.4.2.1 Error Control Procedures for the Receiver 

Upon receiving an LCH, the receiver shall check the LCH's CRC. If the CRC is not correct, the receiver shall discard the 
LCH. Otherwise, the receiver shall perform the following actions: 

if the LCH's sequence number is outside the receiver's window, then discard the LCH; 

if the LCH's sequence number is inside the receiver's window, store the LCH in the receiver's buffer and update 
the variable RxBoW^ if appropriate. 

Upon receiving the discard message, the receiver shall perform the actions described in subclause 6.4.2.12. 

If the receiver is in flow control state, it may discard all LCHs that are above the flow control limit that it has signalled 
to the transmitter, see subclause 6.4.2.14. In this case the receiver sets the flow control indication bit to 1 in the ARQ 
feedback messages. 

6.4.2.1 1 Error Control Procedures for the Transmitter 

In this subclause, Dj, denotes the sequence number set in the latest discard message sent in the current transmit window. 
If no discard message has been sent in the window, Dj, is regarded to be equal to TxBoWj,. 

As a general rule, the transmitter shall keep all LCHs that have not yet been cumulatively acknowledged in its buffer. 
Even if an LCH is positively acknowledged in a bitmap block, the transmitter shall keep it in its memory until it is 
cumulatively acknowledged, and shall be prepared to retransmit it when necessary. 

The transmitter shall not transmit LCHs with sequence numbers outside its window. The transmitter shall transmit new 
LCHs in consecutive ascending order of their sequence numbers. 

Upon receiving an ARQ feedback message with a correct CRC, the transmitter shall perform a logical integrity check on 
it. The check consists of mandatory and optional checks. 

The following check is mandatory: 

if the CAI bit is set to 1 , the lowest negatively acknowledged LCH within BMB 1 in the block with number 
BMNl shall be in the interval [TxBoW^,, TxBoW,,j,H-feJ. 

The following checks are optional: 

- if the relative block numbers BMN2j, or BMN3j, are zero, BMB2 and BMB3 shall be identical to BMB 1 ; 

a positively acknowledged LCH shall be placed within the negotiated window. 

An exception exists for BMB 1 that may contain LCHs outside the window because SNs are signalled in blocks of 8 bits 
and not individually. 

A counter F is set to zero if the logical integrity check of the ARQ feedback message containing the CumAck is correct. 

If the logical integrity check fails, the following actions shall be performed: 
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the ARQ feedback message shall be ignored; 

the counter F shall be incremented by 1 ; 

If F=Fniax=2, the cormection shall be reset following the procedure described in subclause 6.4.2.9. The counter F is 
reset to 0. 

NOTE: If the transmitter's and the receiver's windows get unsynchronized, the following may happen: 

either the receiver's RxBoWj, is within the transmitter's window, and the transmitter updates TxBoWj, based on 
the cumulative acknowledgements received in the ARQ feedback message; or 

the receiver's RxBoW^ is outside the transmitter's window, then the cumulative acknowledgements cause the 
logical integrity checks to fail, and the connection is reset. 

The transmitter shall maintain a timer that shall be reset each time the TxBoWj, is advanced. If this timer reaches a 
threshold value of 5 seconds, the connection shall be reset following the procedure described in subclause 6.4.2.9. The 
timer's status shall be enabled if the transmitter has LCHs waiting for acknowledgements and disabled otherwise. 
Whenever the timer is disabled, it shall be reset. 

When the receiver signals a flow control indication, the transmitter should transmit or retransmit only LCHs that are at 
or below the flow control limit. 

6.4.2.12 Discarding of LCHs 

This subclause describes a mechanism that a transmitter can use if it does not intend to transmit LCHs it has in its 
transmission buffer. The reasons to discard LCHs are out of the scope of the present document. The discard message 
format is given in subclause 6.2. 

6.4.2.1 2.1 Actions of the transmitter 

The discard procedure is initiated by the transmission of a discard message by the transmitter. The Discard sequence 
number shall be inside the transmitter window [TxBoWj,, TxBoW(,j, +kj,). The transmitter's intention of sending the 
discard message is to inform the receiver that it wants to discard the LCHs with SNs up to but not including the discard 
sequence number Dj,. 

The update of the transmit window and the deletion of the LCHs from the buffer shall be performed only after the 
transmitter has received the cumulative acknowledgement, as described in the subsequent subclause. 

The discard sequence number shall be higher or equal than the discard sequence numbers previously sent in the current 
transmit window. 

Whenever the transmitter receives negative acknowledgements from the receiver for LCHs that the transmitter has 
announced in a discard message, the transmitter shall retransmit the discard message in order to make sure that the 
transmission does not stall when the discard message is lost. 

6.4.2.1 2.2 Actions of the receiver 

Upon reception of the discard message, the receiver shall perform the following actions: 

it shall process the discard message after it has processed the LCHs in the same frame. A receiver may process 
the discard message in a later frame than the one in which it has been received, but it shall make sure that the 
same LCHs are discarded as if the message was logically processed in the frame when it was received; 

it checks the CRC of the discard message and ignores the discard message if the CRC is not correct; 

it checks whether the discard sequence number and the repeated discard sequence number fields in the discard 
message are equal. If both sequence numbers are identical, the discard message is processed. If the sequence 
numbers are not identical, the message is ignored; 

it checks whether the discard sequence number is inside its receive window, i.e., it is inside 
[RxBoWj,, RxBoW(^j, + k^). If not, the discard message is ignored; 



£75/ 



70 ETSI TS 101 761-1 V1.1.1 (2000-04) 

if the discard sequence number is inside the receive window, the receiver may deliver the payloads of received 
LCHs starting with SN = RxBoWj, up to the discard sequence number (not included) to the CL. Which LCHs that 
are delivered to the CL is vendor specific; 

it shall set RxBoW^ to the discard sequence number. 

6.4.2.13 Handling of Dynamic ARQ bandwidth allocation 

The number of SCHs available for ARQ feedback messages may change from MAC frame to MAC frame. Therefore the 
number of bitmap blocks that can be signalled in a frame changes dynamically, as determined by the AP scheduler. 

The receiver in the MT may request for more uplink ARQ signalling capacity by setting the ABIR (ARQ Bandwidth 
Increase Request) bit to 1 in the ARQ feedback message. The reason for setting it may be that the MT has an increased 
amount of ARQ messages to transmit, e.g. because of a high number of transmission errors. The decision is up to the 
MT and is out of the scope of the present document. 

NOTE 1 : The ABIR bit is not available for the direct link. 

NOTE 2: The calculation of the amount of extra SCH capacity granted by the scheduler in the AP is out of the 
scope of the present document. 

6.4.2.14 Flow Control 

The receiver may use the FC (Flow Control indication) bit in the ARQ feedback message to control the amount of traffic 
the transmitter transmits. Upon receiving the ARQ feedback message with the FC bit set, at least after an rtt the 
transmitter shall send only LCHs with sequence numbers up to the highest sequence number signalled in the Bitmap 
Blocks included in any previously received ARQ feedback messages. The receiver shall continuously set the FC bit to 1 
as long as it needs the flow control. When the transmitter is completely stopped (i.e. can not send more LCHs due to the 
flow control limitation), the ARQ feedback message request bit (ARB) in the RR is used to request the receiver to send 
ARQ feedback messages in CM. In DM the ARB bit in the RR is used to request the AP/CC scheduler to grant SCHs for 
ARQ feedback messages to the receiver. 

The transmitter shall update the highest bitmap block number upon receipt of any ARQ feedback message independent 
of if the receiver is in flow control mode or not. 

6.4.2.14.1 Receiver actions 

When the receiver is in flow control state, it shall generate ARQ feedback messages containing only such bitmap blocks 
for which it can accept all the corresponding LCHs. The flow control limit is then defined as the highest SN in the ARQ 
feedback messages. If the receiver receives an LCH above its flow control limit, it may discard this LCH. 

A receiver that is in flow control mode need not send a cumulative acknowledgement. This is an exception to the rule 
given in subclause 6.4.2.8. In the case a discard message is received, the receiver may accept and process the discard 
message and send a cumulative acknowledgement, see subclause 6.4.2.12. 

NOTE; When the receiver enters the flow control mode, is out of the scope of the present document. 

6.4.2.14.2 Transmitter actions 

Whenever the flow control bit is set to 1 in an ARQ feedback message, the transmitter shall enter flow control mode. 
When the flow control bit is not set to 1 , the transmitter shall exit the flow control mode. 

In the case the transmitter is an MT, it shall set the number of LCHs requested in RRs at maximum up to the amount 
given by the flow control limit. 

In the case of an MT as a transmitter which is completely stopped (it has LCHs not yet transmitted but transmission is 
not allowed due to flow control), the MT shall send an RR with #LCH=0 and ARB=1. Upon reception of such an RR, 
the AP/CC scheduler should allocate appropriate resources. This allows the transmitter to probe the receiver whether it 
can accept new LCHs. 

NOTE 1 : The timing of when the transmitter sends such a RR with #LCH=0 and ARB= 1 is not specified. 
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NOTE 2: The ARB bit can be used in other occasions, e.g. stalled transmitter window, missing ARQ feedback or 
immediately on entering flow control mode. 

6.4.3 Repetition mode 

6.4.3.1 General 

The EC functions using repetition mode may be applied to UBCHs. 

The error control function is responsible for: 

evaluation and generation of the CRC for LCHs; 

detection of missing LCHs, i.e. LCHs that have not been received yet or detected by the CRC function as 
erroneous; 

handling of LCHs: Where applicable, performing repetition of LCHs. In order delivery of LCHs to the CL; 

generation of discard messages and act accordingly. 

NOTE 1 : The scheduler is responsible for the allocation of resources for discard messages. 

NOTE 2: The transmitter can use arbitrary repetitions of LCH's for UBCHs to improve the reception quality. The 
choice of the use of the repetition scheme is left to each vendor. 

The support of the repetiton mode for the UBCH is mandatory for the receiving side at the MT, optional for the 
transmitting side at the MT and optional for receiving and transmitting side at the AP/CC. 

6.4.3.2 Notations 

The same notation as given in subclause 6.4.2.2 shall be used. 

6.4.3.3 LCH Sequence Number SN 

Each LCH shall be assigned a 10-bit sequence number. Sequence numbers shall be incremented by 1 for subsequent 
LCHs and calculated modulo 2^^. 

Each copy of a specific LCH shall have the same sequence number. 

6.4.3.4 Window Sizes ks 

The window size k^ is conveyed from the AP/CC to the MT when the MT joins a certain convergence layer broadcast, 
see TS 101 761-2 [5]. Possible window sizes are 32, 64, 128, 256. The MT shall accept all combinations. 

6.4.3.5 Acceptance range 

For the exception case where a receiver fails to receive all LCH's despite the transmitter's repetition, the receiver 
window shall be shifted upon reception of LCH's with sequence number outside the receiver window. In order to prevent 
any sequence number to change the receiver window, the receiver shall only accept LCH's that are within the receiver 
acceptance range. 

The acceptance range shall be 512, measured from RxBoWj,, according to: [RxBoW^,; RxBoWj^^ + 512). 

6.4.3.6 Receiver window 

The receiver window is the interval of sequence numbers that are eligible for reception. The bottom of the receiver 
window RxBoWj, shall be the lowest sequence number not yet received correctly by the receiver. 

The receiver window shall be the set of sequence numbers [RxBoW. RxBoW^ + ^ ). 
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6.4.3.7 Transmitter behaviour 



The transmitter shall transmit new LCHs in consecutive ascending order of their sequence numbers. The transmitter is 
allowed to make arbitrary repetitions of each LCH. 

Due to the behaviour of the receiver, the transmitter should keep repetitions of each LCH within the range of the 
receiver window. 

NOTE: Due to for example residual bit errors, the transmitter may not always be able to exactly predict the 
receiver window. 

The exact behaviour of the transmitter is out of the scope of the present document. 

6.4.3.8 Error Control Procedures for the Receiver 

Upon receiving an LCH, the receiver shall check the LCH's CRC. If the CRC is not correct, the receiver shall discard the 
LCH. Otherwise, the receiver shall perform the following actions: 

if the LCH's sequence number is inside the receiver's window, store the PDU in the receiver's buffer and update 
the variable RxBoW^; 

if the LCH's sequence number (X^) is outside the receiver's window, but inside the acceptance range: 

the receiver may deliver the payloads of the correctly received LCHs starting with SN = RxBoWj, up to 
X^- k^+ 1 (not included) to the CL in the order of their sequence numbers; 

- change the RxBoW,, to X^ -ks+ U 

store the PDU in the receiver's buffer; 

if the LCH's sequence number is outside the receiver's acceptance range, then discard the LCH. 

Upon receiving the discard message, the receiver shall perform the actions described in subclause 6.4.2.12. 

EXAMPLE: A Window size of 32 is assumed, see figure 47. 

a) A receiver which has not correctly received the LCHs with SN = and SN = 3. The highest SN 
received is SN = 31. 

b) The MT has received LCH with sequence number 32. It shifts its ToWs and subsequently its 
BoWs, thus LCH with SN is ignored and the LCHs with SNs 1 and 2 may be delivered to the 
convergence layer. 

c) Since 1 and 2 are correctly received, RxBoW^, is moved to SN = 3. 
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Figure 47: Example for shift of thie receive window 



6.4.3.9 



Discarding of LCHs 



6.4.3.9.1 



General 



This subclause describes a mechanism that a transmitter may use in conjunction with the repetition scheme for UBCHs. 
The discard message format is given in subclause 6.2. 

The support and use of this feature is optional for APs/CCs and mandatory for MTs. In order to avoid major delays of 
UBCH messages, it is recommended to use this discard mechanism to overcome situations when incorrect reception at 
the receiver's BoW stalls the UBCH deliverance to the higher layer. 



6.4.3.9.2 



Actions of the transmitter 



The discard procedure shall be initiated by the transmission of a discard message by the transmitter. The transmitter's 
intention of sending the discard message is to inform the receiver that no more repetition will occur up to but not 
including the discard sequence number D^. 

6.4.3.9.3 Actions of the receiver 

The following actions shall be performed upon reception of the discard message: 

it shall process the discard message after it has processed the LCHs in the same frame. The receiver may process 
the discard message in a later frame than the one in which it has been received, but it shall make sure that the 
same LCHs are discarded as if the message was logically processed in the frame during which it has been 
received; 

it checks the CRC of the discard message and ignores the discard message if the CRC is not correct; 
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it checks whether the discard sequence number and the repeated discard sequence number fields in the discard 
message are equal. If both sequence numbers are identical, the discard message is processed. If the sequence 
numbers are not identical, the message is ignored; 

it checks whether the discard sequence number is inside its receive acceptance range, i.e., it is inside 
[RxBoWg, RxBoWj, + 512). If not, the discard message is ignored; 

if the discard sequence number is inside the receivers acceptance range, the receiver may deliver the payloads of 
the correctly received LCHs starting with SN = RxBoW^ up to the discard sequence number (not included) to the 
CL in the order of their sequence numbers; 

it shall set RxBoWj, to the discard sequence number. 

6.4.4 Unacknowledged mode 

6.4.4.1 General 

The EC functions using unacknowledged mode can be applied to UBCHs and UDCHs. It shall be applied to UMCHs, 
the RBCH using LCHs as well as the DCCH using LCHs. The error control function is responsible for: 

evaluation and generation of the CRC for LCHs; 

in order delivery of LCHs to a CL or the RLC, depending on which logical channel the LCH carries; 

- utilize the resource request procedure for UDCH and DCCH, see subclause 6.3.2. 

NOTE: Unacknowledged transmission provides an unreliable transmission with low latency through the DLC 
layer. 

The support of the unacknowledged mode for UDCHs and UBCHs is mandatory for MTs and optional for APs/CCs. 

6.4.4.2 LCH Sequence Number SN 

Each LCH is assigned a 10-bit sequence number. Sequence numbers are incremented by 1 for subsequent LCHs and 
calculated modulo 2^^. 

6.4.4.3 Transmitter actions 

The transmitter shall send the PDUs in ascending sequence number ordering. 

If ARQ feedback messages are received, they shall be ignored by the transmitter. This is also valid for flow control 
indications. 

6.4.4.4 Receiver actions 

• Deliver the correctly received LCHs in the order of their sequence numbers to the convergence layer. 

• Utilize the same rule for the SCH as given in subclause 6.3.2.4, except that ARQ feedback messages shall not be 
transmitted. 

6.5 Multicast transmission 

When a multicast transmission is negotiated in CM, the AP/CC can select to transmit the multicast traffic on a UMCH or 
on a UDCH. If a UDCH is used, the error control mode specified for the particular UDCH shall be used, see 
subclause 6.4. The AP/CC can distribute multicast data to several MTs by using individual UDCH for each MT. If a 
UMCH is used, then the unacknowledged error control mode shall be used, see subclause 6.4.4. 
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In DM, the transmitter of a multicast connection internally decides wether the multicast traffic shall be transmitted on a 
DiL UMCH or on an individual DiL UDCH for each receiver. If a UDCH is used, the error control mode specified for 
the particular UDCH shall be used, see subclause 6.4. If UMCH is used, then the unacknowledged error control mode 
shall be used, see subclause 6.4.4. 

NOTE: Extensions of the DLC may allow for additional error control modes. 



6.6 



CRC calculation 



All messages shall be protected by a CRC. The following procedure is performed: 

1) Preset the shift register to all ones 

2) Shift the data part of the PDU through the shift register with the MSB first, i.e. in the sending order, see 
subclause 5.2.1. 

3) Add the CRC to the message as described for each message type. 

The CRC shall be the remainder generated by the module 2 division by the specified polynomial (see table 2): 

Table 2: CRC polynomial 





G(x) 


CRC-16 


X16 + x12 + x8 + x7 + x6 + x3 + X + 1 


CRC-24 


X24 + x10 + x9 + x6 + x4 + x3 + X + 1 



The protected bits shall be processed in the transmit order. 
Figure 48 shows how to generate the CRC-16. 



CRC-16 polynomial: G(x)=x"'h-x'^h-x**h-x''h-x''h-x^h-xh-1 
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Figure 48: Definition of CRC-16 polynomial 



6.7 Encryption 



6.7.1 



Introduction 



The security solution for HIPERLAN/2 has two main functions, encryption and authentication. Key management is a 
supporting function for both encryption and authentication. The key management and authentication functions are 
described in TS 101 761-2 [5]. 

Encryption provides confidentiality to transferred data. It is possible to encrypt UDCH, UMCH, UBCH and DCCH 
messages carried by LCHs. The downlink RLC broadcast channel, RBCH, that can be carried by LCHs, is not 
encrypted, as it has to reach all MT's. 

If encryption is agreed during association or handover, the unicast encryption shall start as soon as the necessary key 
exchange has taken place during the association or handover procedure as described in TS 101 761-2 [5]. The use of 
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encryption as well as the choice of the encryption algorithm to be used is negotiated between the AP/CC and the MT. 
Encrypted communication for multicast and broadcast may be established after unicast encryption has been set up. 

NOTE: The exact procedures for encryption startup and key management are defined in TS 101 761-2 [5]. The 
encryption keys for uplink and downlink are always between the AP and one or more MTs, whereas in 
DiL it is between a pair of MTs (the CC may also act as an MT in this case). The key management for DM 
communication is defined in TS 101 761-4 (see Bibliography). 

Two encryption algorithms, DES and TripleDES, are used in order to support different security levels. These algorithms 
need an Initialization Vector (IV). Periodical transfer of a seed from the AP/CC to the MT supports the generation of the 
IV in the MT. 

A mapping between the encryption key for DES as well as the ones for TripleDES and a MAC ID is defined in 
TS 101 761-2 [5]. Multicast and broadcast encryption use group specific key(s) or key(s) common to several groups. 
Access restrictions for individual multicast groups are handled on higher layers and are outside the scope of 
HIPERLAN/2. 

6.7.2 Encryption of LCHs 

If encryption and the algorithm has been agreed and the encryption key(s) have been exchanged during the link 
capabihty negotiation, each concerned LCH shall be encrypted completely. 

6.7.3 Algorithms 

Two encryption algorithms are supported: DES (Data Encryption Standard) and TripleDES. The former is mandatory to 
implement for MTs and APs/CCs, whereas the implementation of the latter is optional for APs and MTs. The use is 
negotiated at association and connection setup time, respectively. 

6.7.3.1 DES 

DES is a block cipher that works on 64-bit blocks using a 56-bit key. DES is defined in Data Encryption Standard [1] 
and its different modes in DES Modes of Operation [3]. The DES algorithm has been evaluated for a long time and has 
no known weaknesses, except some weak and semi-weak keys that shall not be used which is described in Guidelines for 
Implementing and Using the Data Encryption Standard [2]. Key handling, including how weak and semi -weak keys shall 
be handled, is described in TS 101 761-2 [5]. 

6.7.3.2 TripleDES 

Triple DES is using the DES algorithm described above three times to offer a higher security level. It shall be run in the 
EDE mode, that is, to use DES to encrypt, decrypt and encrypt in sequence with three different keys. The total key 
length therefore is 3 X 56 = 168 bits. The EDE mode is illustrated in figure 49. 
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Figure 49: TripleDES encryption in OFB mode 

The key handling for TripleDES is described in TS 101 761-2 [5]. 

6.7.4 Encryption and decryption procedure 

Each LCH PDU shall be encrypted and decrypted individually as follows: 

the encryption module is first loaded with a 64-bit/8-octet Initialization Vector (IV). How the IV is generated is 
described in subclause 6.7.7; 

the output from the encryption module (DES or TripleDES), called keystream, is XORed with the first 64-bit 
plaintext block to give the resulting ciphertext. The keystream shall also be fed back to the encryption module in 
order to generate a new keystream for encrypting the next plaintext block, that is the Output FeedBack (OFB) 
mode as described in DES Modes of Operation [3] shall be used; 

the procedure continues until the last plain text block (=6 octets) has been encrypted. The plain text shall be 
encrypted in transmission order, starting with MSB and ending with LSB of the output from the encryption 
module, see subclause 5.2.1. 

The encryption module at the receiver side shall use the same input to generate the keystream as the transmitter side. 
Note that the encryption function, not decryption, is used at the receiving side. The keystream shall be XORed with the 
ciphertext to give the plaintext. The ciphertext shall be decrypted in the receiving order, starting with the MSB and 
ending with the LSB of the output of the encryption module. The procedure is illustrated in figure 50. 
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Figure 50: LCH PDU encryption and decryption 

6.7.5 Encryption keys 

A mapping between MAC IDs and encryption keys is established by RLC signalling. For more information about key 
management (generation, distribution, refresh, etc.) see TS 101 761-2 [5]. 

6.7.6 Encryption Seed 



6.7.6.1 



General 



A seed is used to support the IV generation. While one IV value is valid for only one LCH PDU, one seed value is valid 
for one MAC frame. A seed generator cycles stepwise to produce non-repeating seeds (before it wraps) for each MAC 
frame. 

Start pointers in FCCH Information Elements, in combination with the seed, are responsible for the generation of 
variable IVs for different PDU trains. An IV generator cycles stepwise to produce non-repeating IVs (before it wraps) 
for each LCH in a PDU train. 



6.7.6.2 



Seed generation in the AP 



Both AP and MT shall have a seed generator consisting of a 52-bit linear feedback shift register (LFSR) based on the 
polynomial \^^+x^+l as illustrated in figure 51. The AP shall generate a 52-bit initial value and load its seed generator. 
This initial value may be any random bit sequence, except all "0"s. If a bit sequence with all "0"s is obtained, the AP 
shall make sure that another non all "0" sequence is generated and used as the initial value instead. 

With the initial value loaded, the AP seed generator LFSR produces seeds for MAC frames by cycling stepwise. To 
cycle one step, the LFSR generates the new MSB bit by XORing the b3 and bg bits together and then shifts the original 
content one bit to the right. The new bit sequence formed in the LFSR is then taken as the seed for the next MAC frame 
as illustrated in figure 52. 



£75/ 



79 



ETSI TS 101 761-1 V1.1.1 (2000-04) 





MSB 














LSB 


1— ► 


bsi 


bso 




bs 


b2 


bi 


bo 






r\ 


ii^ 










VJ 


r^ 
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Figure 52: Seed generator output 



6.7.6.3 



Seed transfer 



The AP shall send the seed for the current MAC frame in the RBCH, see figure 53. The AP controls the seed 
transmission and shall ensure that the seed is sent in a proper way to sleeping terminal(s), during handover and 
association, see TS 101 761-2 [5]. The seed shall be transferred in each Nth frame. Further details are defined in 
TS 101 761-2 [5]. 

6.7.6.4 Seed generation in the MT 

The seed generation shall consist of two steps in the following order, see figure 53: 

1) The MT seed generator cycles and produces a seed to be used during the current frame based on the latest correctly 
received seed. 

2) The MT checks whether a seed has been received in the RBCH. If a non-all "0" seed with correct CRC has been 
received, the MT loads/updates its seed generator with the received value. The MT shall not load/update the seed 
generator if a non-correct CRC has been detected. The next output (when the generator has cycled one step) is used 
as the seed for the next MAC frame 
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Figure 53: Seed generation and transmission procedures 

6.7.7 Initialization Vector (IV) 

The initialization vector is used for encrypting/decrypting the first 8 octets of each LCH. Both APs and MTs shall have 
an IV generator which is a 64-bit LFSR using the polynomial x^^+x^+x^+x+ 1 as illustrated in figure 54 to generate a 
new IV for each LCH. 



MSB 



LSB 




Figure 54: IV generator cycle one step 

Before encrypting/decrypting the first LCH PDU for a particular connection, the IV generator LFSR shall be loaded 
with the concatenation of the seed (for the current MAC frame) and the 12 least significant bits of the start pointer value 
(see subclause 6.2.2) in the FCCH IE for that particular connection, see figure 55. 
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Figure 55: IV generator load with seed and 12-bit start pointer 



The current content of the IV generator shall be used as IV bits, see figure 56, for encrypting/decrypting the first 8 octets 
of the first LCH PDU for that particular connection. 

The IV generator LFSR shall cycle one step for each new LCH PDU for that particular connection. That is, the LFSR 
generates the new MSB bit by XORing the h^, h^^, hy and bg bits together and then shifts the original content one bit to 
the right, see figure 54. The new bit sequence formed in the LFSR shall be used as IV for the next LCH PDU. The LFSR 
cycles step by step until the IV for the last LCH PDU of a particular DUC has been generated and used. 
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Figure 56: IV generator output 

6.8 Transmission power 

The rules for the selection of the appropriate transmission power for the different parts in MAC frames are defined in 
TS 101 761-2 [5]. This involves the rules for transmitter power control. 

6.9 IVIapping between IVIAC frame and PHY frame 

6.9.1 Number of OFDIVI symbols per transport channel excluding physical 
layer preambles 

The number of OFDM symbols per transport channels is shown in table 34. 

Table 34: Number of OFDM symbols per transport channel excluding physical layer preambles 



PHY mode 


BCH,15oct. 


FCH, 27oct. 


ACH, 9 oct. 


SCH, 9 oct. 


LCH, 54 oct. 


RCH, 9 oct. 


BPSK, coderate=1/2 


5 


9 


3 


3 


18 


3 


BPSK, code rate=3/4 


- 


- 




2 


12 


- 


QPSK, coderate=1/2 


- 


- 




- 


9 


- 


QPSK, code rate=3/4 


- 


- 




1 


6 


- 


16QAM, coderate=9/16 


- 


- 




- 


4 


- 


1 6QAM, code rate=3/4 


- 


- 




- 


3 


- 


64QAM, code rate=3/4 


- 


- 




- 


2 


- 



The FCH in the table refers to one IE block of 27 octets. 
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The Duration of one OFDM symbol is equal to 4 |is if the long guard interval is used or 3.6 |is if the short guard interval 
is used. The long guard interval is mandatory to support and is the default value, i.e. it is used if not negotiated 
otherwise. The short guard interval is optional and can be used for SCHs and LCHs that carry a UDCH and its 
corresponding LCCH. The support of the short guard interval by both MT and AP/CC is negotiated during association 
or handover. The use of the short interval is negotiated for each individual DUC, i.e. for a UDCH, during DLC 
connection set up. Further details can be found in TS 101 475 [4] and TS 101 761-2 [5]. 

6.9.2 PDU trains 



6.9.2.1 



General 



The radio subsystem provides a set of transport channels describing the message format over the air interface. Transport 
channels are used as basic elements in constructing PDU trains. The PDU trains that consist of a sequence of transport 
channels represent the interface between the DLC and the PHY layer: 

1) Broadcast PDU train. 

2) FCH-and-ACH PDU train. 

3) Downlink PDU train. 

4) Uplink PDU train with short preamble. 

5) Uplink PDU train with long preamble. 

6) Direct link PDU train. 

NOTE: The preambles in the following figures are not a part of the DLC PDU train. They are added by the PHY 
layer, see TS 101475 [4]. 



6.9.2.2 



Broadcast PDU train 



The Broadcast PDU train can have the formats according to figure 57 depending on the number of sectors the AP uses. 
The upper drawing applies to the case of a single sector, the lower drawing to multiple sectors. In the case of multiple 
sectors, each BCH is transmitted using an individual broadcast PDU train. 



Number of sectors per AP = 1 



Preamble 


BCH 


FCH 


ACH 



Preamble 


BCH 



number of sectors per AP > 1 

Figure 57: Possible Broadcast PDU trains 

The preamble of the BCH shall consist of 4 OFDM symbols (16 |as), see TS 101 475 [4]. 



6.9.2.3 



FCH-and-ACH PDU train 



One preamble shall be added in the beginning of each FCH-and-ACH PDU train if multiple sectors are used per AP. 
The preamble of the FCH-and-ACH PDU train shall be 2 OFDM symbols, see TS 101 475 [4]. Possible FCH-and-ACH 
PDU trains are shown in figure 58. The upper drawing shows the case where an FCH is present, whereas the length of 
the FCH is zero in the lower drawing. 



Preamble 


FCH 


ACH 






Preamble 


ACH 





Figure 58: Possible FCH-and-ACH PDU trains 
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6.9.2.4 



Downlink PDU train 



One preamble shall be added at the beginning of each downlink PDU train, see figure 59. The preamble of the Downlink 
PDU train shall have a length of 2 OFDM symbols, see TS 101 475 [4]. 

A set of SCHs and LCHs is granted for each DLCC by one RG. An MT shall receive not more than one downlink PDU 
train containing UDCHs, the DCCH and LCCHs per MAC frame, i.e. all corresponding DLCCs shall be grouped in a 
single PDU train. It shall receive the RBCH, UMCHs and UBCHs in separate PDU trains. 
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ID k, MAC ID i 




r 




"N 


Preamble 


SCHs 


LCHs 


SCHs 


LCHs 



DLCC -ID m 


MAC ID i 
A 




r 


N 




SCHs 


LCHs 



Figure 59: Possible downlink PDU train 



6.9.2.5 



Uplink PDU train with short preamble 



One preamble shall be added at the beginning of each uplink PDU train, see figure 60. The preamble used for uplink 
PDU trains is announced in the BCCH in the "uplink preamble" field which is set to zero for the short preamble. The 
preamble of the uplink PDU train with short preamble shall have a length of 3 OFDM symbols, see TS 101 475 [4]. 

A number of SCHs and LCHs is granted for each DLCC by one RG. An MT shall be granted not more than one uplink 
PDU train for the transmission of data, i.e. all corresponding DLCCs shall be grouped in a single PDU train. 
Additionally it may make an access attempt to the RCH. 
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DLCC-ID k MAC ID i 
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Preamble 
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6.9.2.6 



Figure 60: Possible uplink PDU train with short preamble 



Uplink PDU train with long preamble 



One preamble shall be added at the beginning of each uplink PDU train, see figure 61 . The preamble used for uplink 
PDU trains is announced in the BCCH in the "uplink preamble" field which is set to 1 for the long preamble. The 
preamble of the uplink PDU train with long preamble shall have a length of 4 OFDM symbols, see TS 101 475 [4]. 

A set of SCHs and LCHs is granted for each DLCC by one RG. An MT shall be granted not more than one uplink PDU 
train for the transmission of data, i.e. all corresponding DLCCs shall be grouped in a single PDU train. Additionally it 
may make an access attempt to the RCH. 
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Figure 61 : Possible uplink PDU train with long preamble 
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6.9.2.7 



Direct link PDU train 



One preamble shall be added at the beginning of each direct link PDU train, see figure 62. The preamble of the direct 
hnk PDU train shall have a length of 4 OFDM symbols, see TS 101 475 [4]. 

A direct link PDU train shall consist of all LCHs and SCHs belonging to the same pair of source and destination MAC 
IDs. A set of SCHs and LCHs is granted for each DLCC by one RG. An MT shall receive not more than one direct link 
PDU train containing UDCHs, DCCHs, and LCCHs per MAC frame per source MAC ID, i.e. all corresponding DLCCs 
shall be grouped in a single PDU train. A receiver may receive the RBCH, UMCHs, and UBCHs from the same 
transmitter in separate PDU trains. 

DLCC-IDj,MTitoMTj DLCC-ID k, MT i to MT j DLCC-ID m, MT i to MT j 

A A X 



Preamble 


LCHs 


SCHs 


LCHs 


SCHs 



LCHs 



SCHs 



6.9.3 



Figure 62: Direct linlt PDU train 

PHY modes for transport channels and special cases for logical 
channels 



The possible PHY modes that can be used for the different transport channels are listed in table 3. 

Table 3: Possible PHY modes for transport channels 



PHY mode 


PHY mode identifier: FCH 


PHY mode identifier: SCH 


PHY mode identifier: LCH 


BPSK, code rate=1/2 


00 


000 


0000 


BPSK, code rate=3/4 


- 


001 


0001 


QPSK, coderate=1/2 


- 


- 


0100 


QPSK, code rate=3/4 


- 


011 


0011 


16QAM, coderate=9/16 


- 


- 


0010 


16QAM, coderate=3/4 


- 


- 


0101 


64QAM, code rate=3/4 


- 


- 


0111 



The remaining unspecified PHY mode identifiers for the FCH are for future use. 

The remaining unspecified PHY mode identifiers for the SCH are for future use. 

The remaining unspecified PHY mode identifiers for the LCH are for future use. 

The BCH, ACH, and RCH shall use BPSK with code rate Vi. The logical channel RBCH using SCHs and LCHs shall 
use BPSK with code rate Vi. The PHY mode of all other logical channels shall be set in the corresponding RG. 

6.9.4 Guard times 



6.9.4.1 



Radio turn-around times 



The maximum radio turn-around time (switch from transmit to receive and vice versa) is 6 |ls, see TS 101 475 [4]. The 
AP/CC shall separate an MT's receive and transmit opportunities by at least the radio turn-around time. 



6.9.4.2 



Propagation delay guard times 



A guard time between uplink PDU trains, and/or between DiL PDU trains shall be inserted by the AP/CC scheduler in 
order to cope with propagation delays. The method to select an appropriate guard time is out of the scope of the present 
document. The guard time between RCHs is announced in the BCCH. 

A minimum guard time is specified in TS 101 475 [4]. To compensate for large propagation delays, an increased guard 
time can be used by the access point. 
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6.9.4.3 



Sector switch guard time 



The time to switch sectors is below 800 ns, see TS 101 475 [4]. The AP/CC scheduler shall take this time to sector 
switching into account by introducing an appropriate time interval whenever the sector is changed. 

The duration of the time interval shall be 800 ns between different broadcast PDU trains, between different FCH-and- 
ACH PDU trains as well as between the last broadcast PDU train and the first FCH-and-ACH PDU train. This is further 
explained by the drawing in figure 63. 

NOTE 1 : The interval defined in the paragraph above is fixed in order to enable MTs to correctly calculate the 
reference point, see subclause 6.3.5.1. 

For all other guard times, its duration depends on the implementation and is out of the scope of this specification. 

NOTE 2: This interval need not be inserted in the case of radio turn-around time and RF carrier change, see 
TS 101 475 [4]. 
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Figure 63: Guard times due to sector switching in the transmission of BCIHs, FCIHs and ACIHs 
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